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

Re: Building wxt terminal for OS X

[<tim...@en...>]

Joe Koski wrote:
> on 10/9/06 2:07 PM, Timoth=E9e Lecomte at tim...@en... wrote=
:
>
>  =20
>> Joe Koski wrote:
>>    =20
>>> on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wro=
te:
>>>
>>>  =20
>>>      =20
>>>> Hi Joe !
>>>>
>>>> I'm sorry you did not succeed, but those errors are normal: wxWidget=
s
>>>> comes in different flavours depending on the platform: wxGTK (as Eth=
an
>>>> told you), wxMSW for Windows, wxMAC which you logically installed, a=
nd
>>>> others. There are a couple of places where it is necessary to choose
>>>> between two possible behaviours (two threads or one) in the terminal
>>>> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW),=
 I
>>>> have chosen to enable the compilation for those two only.
>>>>
>>>> However, attached is a patch that enables the compilation for wxMAC.=
 I
>>>> will be very glad to see you try it. Apply it in src/wxterminal and =
try
>>>> to build again. Hopefully it will work. Don't hesitate to report any=
 issue.
>>>>
>>>> Thank you very much for your efforts.
>>>>
>>>> Best regards,
>>>>
>>>> Timoth=E9e
>>>>    =20
>>>>        =20
>>> Timoth=E9e,
>>>
>>> I applied the patch, borrowed fontconfig from X11 with an export
>>> PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt te=
rminal.
>>> (I'll send you a screen shot separately.)
>>>
>>> To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x=
) to
>>> see what would happen.
>>>  =20
>>>      =20
>> The plot is rendered properly, that's a good point !
>>
>>    =20
>>> I got the plot, but I could not get "focus" or whatever you call it f=
or the
>>> plot window. When I placed the cursor in the plot window area, all I =
get was
>>> a twirling icon telling me to wait. This happens any time the cursor =
crosses
>>> the wxt window.
>>>      =20
>> Do you mean that the plot window is just like dead ? Is the cursor
>> position updated in the status bar for example ?
>> If it's the case, there is probably an issue with the GUI loop running
>> in a separate thread.
>>
>>    =20
> Timoth=E9e,
>
> I realized after I sent the message I should have been more clear on th=
is
> point. Clicking inside the window does not get the focus, and the bar a=
t the
> top is always grayed out as it is in the screen shot that I sent you. Y=
our
> question about the screen being "dead" is a good description.
I'm not familiar at all with MacOS. Is it a behaviour that you've=20
already observed in other situations ? (with X11, when the application=20
is dead, the screen is no longer updated and you get gray surfaces when=20
you drag another app on top of the dead one, for example)


> The cursor
> position at the lower left is frozen as it shows in the screen shot, an=
d
> does not change when you move the cursor.
>
> I have done a bit more testing. I can get octave-2.9.9 to open wxt wind=
ows,
> and display plots,

Can you display several plots successively ? That would be another=20
argument in favor of the dead gui thread, because the plot rendering is=20
done in the main thread.

> which is good, but it doesn't display legend information
> that displays in both X11 and AquaTerm.
Do you mean the mouse cursor position as above ?

Thanks, best regards,

Timoth=E9e

How to automaticaly label points in gnuplot ?

[Fabien S. <fab...@tu...>]

Hi !
I wonder if it is possible to set labels automaticaly in gnuplot
Is it possible to label, in a function curve, indiquating a column where the 
point's names are ?

Thank you
F.S.

Date/Time (xrange) wont work

[Nibbler <rea...@ho...>]

Hi.

I would like to set date/time in the x-range.
My date/time is like this: 2006-10-05 10:30:05.
How I should set timefmt so the gnuplot would understand the the time
format? 

I have tried to do like this, 
set timefmt "%Y/%m/%d\t%H:%M:%S"
but when I run gnuplot the x-axel shows only the date. Not the time.

Thanks. 

-- 
View this message in context: http://www.nabble.com/Date-Time-%28xrange%29-wont-work-tf2414481.html#a6730135
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Problem with pause -1 ?

[Joe K. <jko...@co...>]

on 10/9/06 8:15 PM, Ethan A Merritt at merritt@u.washington.edu wrote:

> On Monday 09 October 2006 05:59 pm, Joe Koski wrote:
>> 
>> First, the script doesn't pause for a carriage return at pause -1
> 
> That is correct.
> You cannot control the execution of a script using 'pause -1'.
> 
> Here is why:
> 'pause -1' means "wait until more input is available".
> In a keyboard session, this means in effect "wait until the
> guy behind the keyboard types something".  But in a scripted
> session, more input is *always* available, right up until you
> run off the end of the script.
> 
>> Shouldn't pause -1 work, even in script input mode?
> 
> No.  What would it mean?  Pause until....what, exactly?
> You can tell it "pause mouse" instead, if you like.
> Then it will wait for a mouse click, even if you are
> in a script.
> 
>> Tell me if I should submit this as a bug report.
> 
> Nope.

Ethan,

OK, the reason I had never worried about this was because I had always used
aquaterm with gnuplot, maxima and octave. The aquaterm terminal separately
pops up the plot window and keeps it until it is later closed or aquaterm is
quit. If I had used X11, I would have seen this behavior before. I guess
having a separate application as the terminal has at least one minor
advantage to slow learners.

Thanks.

Joe

Re: Problem with pause -1 ?

[Joe K. <jko...@co...>]

on 10/9/06 7:33 PM, Daniel J Sebald at dan...@ie... wrote:

> Joe Koski wrote:
> 
>> Shouldn't pause -1 work, even in script input mode? Otherwise the plot just
>> flashes by. What happens to the s in set?
> 
> The "s" is the character interpretted as a carriage return.
> 
>> The problem is identical with the wxt terminal.
>> 
>> Tell me if I should submit this as a bug report. Thanks.
> 
> Probably not.  The redirection < replaces the keyboard input with with the
> file contents.  Not sure how one can "pause" the input from a file.  (Not
> hitting the keyboard is the pause.)
> 
> Give this a try:
> 
> gnuplot test_script.inp
> 
> 
> Dan

Dan, You are correct. gnuplot test_script.inp works as I expected it should.
Thanks.
Joe

Re: Problem with pause -1 ?

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

On Monday 09 October 2006 05:59 pm, Joe Koski wrote:
> 
> First, the script doesn't pause for a carriage return at pause -1

That is correct.
You cannot control the execution of a script using 'pause -1'.

Here is why:
'pause -1' means "wait until more input is available".
In a keyboard session, this means in effect "wait until the
guy behind the keyboard types something".  But in a scripted
session, more input is *always* available, right up until you
run off the end of the script.

> Shouldn't pause -1 work, even in script input mode? 

No.  What would it mean?  Pause until....what, exactly?
You can tell it "pause mouse" instead, if you like.
Then it will wait for a mouse click, even if you are
in a script.

> Tell me if I should submit this as a bug report.

Nope.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Problem with pause -1 ?

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

Joe Koski wrote:

> Shouldn't pause -1 work, even in script input mode? Otherwise the plot just
> flashes by. What happens to the s in set?

The "s" is the character interpretted as a carriage return.

> The problem is identical with the wxt terminal.
> 
> Tell me if I should submit this as a bug report. Thanks.

Probably not.  The redirection < replaces the keyboard input with with the file contents.  Not sure how one can "pause" the input from a file.  (Not hitting the keyboard is the pause.)

Give this a try:

gnuplot test_script.inp


Dan

Problem with pause -1 ?

[Joe K. <jko...@co...>]

Hi, all

While testing the wxt terminal, I ran across a problem with my perception of
the way gnuplot-4.2.rc1 should work. The problem also occurs with x11, so
here it is. This is on my G5 Mac with OS X 10.4.8, built with Xcode-2.4
developer tools, etc.

I test a simple script with gnuplot < test_script.inp, where test_script is

set term x11
plot [-pi:pi] sin(x)
pause -1
set term postscript color
set output "test_plot.ps"
replot

First, the script doesn't pause for a carriage return at pause -1, then I
see

Joe-Koskis-Computer:~/Codes/gnuplot_tests jakoski$ gnuplot < test_script.inp

gnuplot> et term postscript color
         ^
         line 0: invalid command

Joe-Koskis-Computer:~/Codes/gnuplot_tests jakoski$

Shouldn't pause -1 work, even in script input mode? Otherwise the plot just
flashes by. What happens to the s in set?

The problem is identical with the wxt terminal.

Tell me if I should submit this as a bug report. Thanks.

Joe

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 10/9/06 2:07 PM, Timoth=E9e Lecomte at tim...@en... wrote:

> Joe Koski wrote:
>> on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote:
>>=20
>>  =20
>>> Hi Joe !
>>>=20
>>> I'm sorry you did not succeed, but those errors are normal: wxWidgets
>>> comes in different flavours depending on the platform: wxGTK (as Ethan
>>> told you), wxMSW for Windows, wxMAC which you logically installed, and
>>> others. There are a couple of places where it is necessary to choose
>>> between two possible behaviours (two threads or one) in the terminal
>>> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), I
>>> have chosen to enable the compilation for those two only.
>>>=20
>>> However, attached is a patch that enables the compilation for wxMAC. I
>>> will be very glad to see you try it. Apply it in src/wxterminal and try
>>> to build again. Hopefully it will work. Don't hesitate to report any is=
sue.
>>>=20
>>> Thank you very much for your efforts.
>>>=20
>>> Best regards,
>>>=20
>>> Timoth=E9e
>>>    =20
>>=20
>> Timoth=E9e,
>>=20
>> I applied the patch, borrowed fontconfig from X11 with an export
>> PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt termi=
nal.
>> (I'll send you a screen shot separately.)
>>=20
>> To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x) t=
o
>> see what would happen.
>>  =20
>=20
> The plot is rendered properly, that's a good point !
>=20
>> I got the plot, but I could not get "focus" or whatever you call it for =
the
>> plot window. When I placed the cursor in the plot window area, all I get=
 was
>> a twirling icon telling me to wait. This happens any time the cursor cro=
sses
>> the wxt window.
> Do you mean that the plot window is just like dead ? Is the cursor
> position updated in the status bar for example ?
> If it's the case, there is probably an issue with the GUI loop running
> in a separate thread.
>=20
Timoth=E9e,

I realized after I sent the message I should have been more clear on this
point. Clicking inside the window does not get the focus, and the bar at th=
e
top is always grayed out as it is in the screen shot that I sent you. Your
question about the screen being "dead" is a good description. The cursor
position at the lower left is frozen as it shows in the screen shot, and
does not change when you move the cursor.

I have done a bit more testing. I can get octave-2.9.9 to open wxt windows,
and display plots, which is good, but it doesn't display legend information
that displays in both X11 and AquaTerm. Fixing that can wait until we have =
a
more workable arrangement.

I'm still waiting for an answer for my fontconfig question about
installation. Using the X11 fontconfig is not the best solution.

Let me know if if I need to try something else.

Joe



>=20
>> When I quit gnuplot, the plot window also disappeared.
>>=20
>> During the build I saw
>>=20
>> (...)set.c: In function 'set_mouse':
>> set.c:2309: warning: pointer targets in passing argument 2 of 'map_posit=
ion'
>> differ in signedness
>> set.c:2309: warning: pointer targets in passing argument 3 of 'map_posit=
ion'
>> differ in signedness
>>=20
>> But I don't know if this is significant.
> It's not relevant to your problem.
>=20
>> What should I be looking for?
>>  =20
> Good question. I'll try to look at some wxMAC code in the next days, and
> I'll send you a patch as soon as I see what could happen.
>=20
>=20
>> I'm available for further builds and testing. Let me know what to try ne=
xt.
>>=20
>> Joe
>>  =20
> Thank you very much.
>=20
> Best regards,
>=20
> Timoth=E9e

Re: Building wxt terminal for OS X

[<tim...@en...>]

Joe Koski wrote:
> on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote=
:
>
>  =20
>> Hi Joe !
>>
>> I'm sorry you did not succeed, but those errors are normal: wxWidgets
>> comes in different flavours depending on the platform: wxGTK (as Ethan
>> told you), wxMSW for Windows, wxMAC which you logically installed, and
>> others. There are a couple of places where it is necessary to choose
>> between two possible behaviours (two threads or one) in the terminal
>> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), I
>> have chosen to enable the compilation for those two only.
>>
>> However, attached is a patch that enables the compilation for wxMAC. I
>> will be very glad to see you try it. Apply it in src/wxterminal and tr=
y
>> to build again. Hopefully it will work. Don't hesitate to report any i=
ssue.
>>
>> Thank you very much for your efforts.
>>
>> Best regards,
>>
>> Timoth=E9e
>>    =20
>
> Timoth=E9e,
>
> I applied the patch, borrowed fontconfig from X11 with an export
> PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt term=
inal.
> (I'll send you a screen shot separately.)
>
> To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x) =
to
> see what would happen.
>  =20

The plot is rendered properly, that's a good point !

> I got the plot, but I could not get "focus" or whatever you call it for=
 the
> plot window. When I placed the cursor in the plot window area, all I ge=
t was
> a twirling icon telling me to wait. This happens any time the cursor cr=
osses
> the wxt window.
Do you mean that the plot window is just like dead ? Is the cursor=20
position updated in the status bar for example ?
If it's the case, there is probably an issue with the GUI loop running=20
in a separate thread.


> When I quit gnuplot, the plot window also disappeared.
>
> During the build I saw
>
> (...)set.c: In function 'set_mouse':
> set.c:2309: warning: pointer targets in passing argument 2 of 'map_posi=
tion'
> differ in signedness
> set.c:2309: warning: pointer targets in passing argument 3 of 'map_posi=
tion'
> differ in signedness
>
> But I don't know if this is significant.
It's not relevant to your problem.

> What should I be looking for?
>  =20
Good question. I'll try to look at some wxMAC code in the next days, and=20
I'll send you a patch as soon as I see what could happen.


> I'm available for further builds and testing. Let me know what to try n=
ext.
>
> Joe
>  =20
Thank you very much.

Best regards,

Timoth=E9e

Re: Gentlemen, start your engines...

[<tim...@en...>]

Lars Hecking wrote:
>  My mails still haven't appeared on the list ...
>
> Timoth?e Lecomte writes:
> [...]=20
>  =20
>> Moreover, there is a problem with gd on systems where GNU libiconv is=20
>> installed. In this case, gnuplot has to be linked against libiconv too=
,=20
>> or undefined references are obtained. The first offender here is=20
>> gdlib-config itself which doesn't report correctly '-liconv' but a ful=
l=20
>> path to libiconv.so. But even if gd gets fixed in a future release (I=20
>> will send the corresponding patch to M. Boutell soon), the configure=20
>> script would not catch it since it doesn't take 'gdlib-config --libs'=20
>> into account. The attached patch fixes this issue too.
>>    =20
>
>  I now understand this problem. Linking with gd also requires iconv in
>  some cases, but gdlib-config provides iconv in --libs, which we only
>  use after configure comes back positive for gd - chicken and egg.
>
>  The only solution I can offer is to do no configure checks for gd at a=
ll
>  if gdlib-config is found. Potentially for pdflib, too.
>  =20
What about the attached solution (posted a few days ago) ?
(ignore if you want the changes for AC_ARG_VAR and $GDLIB_CONFIG,=20
although they are useful too)

Best regards,

Timoth=E9e

Re: Gentlemen, start your engines...

[Lars H. <lhe...@us...>]

 My mails still haven't appeared on the list ...

Timoth?e Lecomte writes:
[...] 
> Moreover, there is a problem with gd on systems where GNU libiconv is 
> installed. In this case, gnuplot has to be linked against libiconv too, 
> or undefined references are obtained. The first offender here is 
> gdlib-config itself which doesn't report correctly '-liconv' but a full 
> path to libiconv.so. But even if gd gets fixed in a future release (I 
> will send the corresponding patch to M. Boutell soon), the configure 
> script would not catch it since it doesn't take 'gdlib-config --libs' 
> into account. The attached patch fixes this issue too.

 I now understand this problem. Linking with gd also requires iconv in
 some cases, but gdlib-config provides iconv in --libs, which we only
 use after configure comes back positive for gd - chicken and egg.

 The only solution I can offer is to do no configure checks for gd at all
 if gdlib-config is found. Potentially for pdflib, too.

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote:

> Hi Joe !
>=20
> I'm sorry you did not succeed, but those errors are normal: wxWidgets
> comes in different flavours depending on the platform: wxGTK (as Ethan
> told you), wxMSW for Windows, wxMAC which you logically installed, and
> others. There are a couple of places where it is necessary to choose
> between two possible behaviours (two threads or one) in the terminal
> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), I
> have chosen to enable the compilation for those two only.
>=20
> However, attached is a patch that enables the compilation for wxMAC. I
> will be very glad to see you try it. Apply it in src/wxterminal and try
> to build again. Hopefully it will work. Don't hesitate to report any issu=
e.
>=20
> Thank you very much for your efforts.
>=20
> Best regards,
>=20
> Timoth=E9e

Timoth=E9e,

I applied the patch, borrowed fontconfig from X11 with an export
PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt terminal=
.
(I'll send you a screen shot separately.)

To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x) to
see what would happen.

I got the plot, but I could not get "focus" or whatever you call it for the
plot window. When I placed the cursor in the plot window area, all I get wa=
s
a twirling icon telling me to wait. This happens any time the cursor crosse=
s
the wxt window. When I quit gnuplot, the plot window also disappeared.

During the build I saw

if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=3D\"/Tools/gnuplot-4.2/usr/local/bin\"
-DX11_DRIVER_DIR=3D\"/Tools/gnuplot-4.2/usr/local/libexec/gnuplot/4.2\"
-DGNUPLOT_PS_DIR=3D\"/Tools/gnuplot-4.2/usr/local/share/gnuplot/4.2/PostScrip=
t
\" -DCONTACT=3D\"gnu...@li...\"
-DHELPFILE=3D\"/Tools/gnuplot-4.2/usr/local/share/gnuplot/4.2/gnuplot.gih\"
-I/usr/X11R6/include -I/usr/local/include/cairo
-I/usr/local/include/freetype2 -I/usr/local/include
-I/usr/local/include/libpng12 -I/usr/local/include/pango-1.0
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include    -g -O2
-ObjC -MT set.o -MD -MP -MF ".deps/set.Tpo" -c -o set.o set.c; \
then mv -f ".deps/set.Tpo" ".deps/set.Po"; else rm -f ".deps/set.Tpo"; exit
1; fi
set.c: In function 'set_mouse':
set.c:2309: warning: pointer targets in passing argument 2 of 'map_position=
'
differ in signedness
set.c:2309: warning: pointer targets in passing argument 3 of 'map_position=
'
differ in signedness

But I don't know if this is significant. What should I be looking for?

I think that this is remarkable progress for a first attempt. I still need
to get a full build of fontconfig to work independently from X11, and I hav=
e
a question submitted to the fontconfig help list to try to get that "make
install" problem resolved.

I'm available for further builds and testing. Let me know what to try next.

Joe

Re: Suggestion to improve usability of plot command

[Theo H. <th...@ph...>]

Keir Mierle wrote:
> I have a simple suggestion to improve the usability of the plot command.
> Currently, I am not a huge fan of the way point styles are specified; mainly
> because I do not find having to memorize different plot styles as numbers
> remotely intuitive. Also, it is very difficult to tell from the documentation
> exactly how to plot squares or other points instead of crosses (for, i.e.
> overplotting two scatter plots to see where points line up).
> 
> What am I suggesting? Instead of writing:
> 
> gnuplot> plot 'file1' with points 4 3
> gnuplot> plot 'file2' with points 1 4
> 
> I suggest that we support (*in addition* not instead of) two new methods of
> specifying plot styles, one which follows the convention of Matlab and Matplotlib
> (Python's plotting package), and another which is so blatently obvious everyone
> will understand it.
> 
> Note that in the above script, no one could possibly guess what 4 3 or 1 4
> means if they are not a frequent gnuplot user. I actually did not figure out
> that this was the command I was looking for until after several passes through
> the documentation; I erroneously expected the command to be obvious.
> 
> 1) The really obvious version
> -----------------------------
> 
> gnuplot> plot 'file1' with points 'red squares'
> gnuplot> plot 'file2' with points 'blue crosses'
> gnuplot> plot 'file1' with points 'orange octagons'
> gnuplot> plot 'file1' with points 'orange stippled-squares'
> gnuplot> plot 'file1' with points 'violet filled-circles'
[...]

First of all: after reading this thread, I'm surprised no one has 
mentioned the `test` command. From `help plot style`: "If you wish to 
choose the line or point type for a single plot, <line_type> and 
<point_type> may be specified. These are positive integer constants (or 
expressions) that specify the line type and point type to be used for 
the plot. Use `test` to display the types available for your terminal."

The "really obvious" syntax can be implemented using macros. See `help 
macros` for an example. It may be that a single command file containing 
macro definitions may be shared among many terminals (for example, the 
postscript-based ones), although certainly some terminals will demand 
their own macro definitions due to differing line- and point types. Feel 
free to contribute such macro definitions for commonly used terminals.

THeo

Re: Suggestion to improve usability of plot command

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

> This was not obvious to me in the documentation.  After digging around, I found
> an example of the new syntax hidden in the variable point size demo in the
> gnuplot 4.2 examples.
>
> Before I continue, I must say thank you for writing gnuplot, and for
> documenting it. I realize documentation is a thankless job. It is odd to think
> that the best comments one can hope for with documentation are none at all.
>
> Now, having said that, let's take this from a new users (my) perspective. All
> I want to accomplish is to control the scatter plot symbols.

A new user should read "Tutorials, learning, help" and to go through 
"Demos", all on the web page. Reading the complete documentation is not what 
a novice should do. This is valid for any other software tool as well.

---
PM

Re: Suggestion to improve usability of plot command

[<br...@ph...>]

Daniel J Sebald wrote:

> I don't know if the problem is so much the use of numbers for me.  The 
> problem is the fact that the numbers don't produce the same symbols 
> across drivers.  

These two are, actually, the same problem.  We use numbers *because* 
they're the lowest common denominator of that every terminal driver can 
use: a sequence of point types that will be used repeatedly as often as 
necessary.

> Why couldn't those be mapped to be similar symbols?  

Because terminal drivers' capabilities differ so much.

> It is very frustrating to create a plot on the screen, 

You're blinding yourself to the difference between "creating" and 
"fine-tuning" here.

> then save it as PostScript to find the symbols are different.

So don't do that then.  Ghostview & friends exist: use them.

> In that sense, I'd say gnuplot isn't script compatible.

Setting aside recent additions like 'linecolour', it is and always has 
been as compatible as it could possibly be: every terminal driver can 
use every plot script and process it, without warnings or errors.  The 
worst that can happen is that the output is harder to read than it was 
on the terminal it was designed for.

Re: Suggestion to improve usability of plot command

[<br...@ph...>]

Keir Mierle wrote:
>> Keir Mierle wrote:
>>> I have a simple suggestion to improve the usability of the plot command.
>>> Currently, I am not a huge fan of the way point styles are specified; 

>> Not very surprisingly --- the syntax you use has never actually been 
>> documented, and has been deprecated for a *long* time now.  The current 
>> syntax, while still oriented towards numbers, is a lot clearer than

> This was not obvious to me in the documentation.  After digging around, I found
> an example of the new syntax hidden in the variable point size demo in the
> gnuplot 4.2 examples.

Interesting.  I really wonder how you managed to miss 'help plot with'.

> Now, having said that, let's take this from a new users (my) perspective. All
> I want to accomplish is to control the scatter plot symbols.
> 
>    1) I go to gnuplot.info. I click on the obvious Documentation link (good).

Bad first reflex.  Why is it so many people these days seems to assume 
that the obvious first place to search for documentation of some tool is 
the web?

>    2) A page with a bunch of information comes up about the different formats
>       available. Not clear exactly which link I should click; since I prefer
>       searchable HTML for documentation, 

Bad second reflex.  There's no such thing as searchable HTML.  Searching 
HTML is a job for a program that has nothing to do with the HTML 
document as such.  To make HTML documents searchable takes an extension 
to the web server --- we don't have that kind of control over our servers.

> Yet, *still*, nowhere does it say 'to plot with circles, use this 
> style.' I had to do trial and error to find the right symbol.

Of course it doesn't.  Because there's no such thing as a particular 
point symbol type that will generate circles on all terminals.  The 
reason for that being that there are terminals that can't do circles.

> I address this in my other follow-up. I would also like to mention that I feel
> when choices of symbol types are deliberate, it is unfortunate that gnuplot
> does not guarentee the same symbols across terminals.

It can't --- terminals are too different for that.

Re: Suggestion to improve usability of plot command

[Keir M. <ke...@cs...>]

> Keir Mierle wrote:
> >I have a simple suggestion to improve the usability of the plot command.
> >Currently, I am not a huge fan of the way point styles are specified; 
> 
> Not very surprisingly --- the syntax you use has never actually been 
> documented, and has been deprecated for a *long* time now.  The current 
> syntax, while still oriented towards numbers, is a lot clearer than

This was not obvious to me in the documentation.  After digging around, I found
an example of the new syntax hidden in the variable point size demo in the
gnuplot 4.2 examples.

Before I continue, I must say thank you for writing gnuplot, and for
documenting it. I realize documentation is a thankless job. It is odd to think
that the best comments one can hope for with documentation are none at all.

Now, having said that, let's take this from a new users (my) perspective. All
I want to accomplish is to control the scatter plot symbols.

   1) I go to gnuplot.info. I click on the obvious Documentation link (good).
   2) A page with a bunch of information comes up about the different formats
      available. Not clear exactly which link I should click; since I prefer
      searchable HTML for documentation, I click the HTML link under 'Official
      gnuplot Documentation'.
   3) In the official documentation, I accidentally page down past the table of
      contents, because it lacks numbers or subsections, which I expect in
      documentation table of contents.  I hit 'home' to go back to the top of
      the page when I realize I'm not finding what I want.
   4) I finally realize that the table of contents is the bulleted list 
      immediately following the big `gnuplot'. I click on Plotting.
   5) I see a bunch of text, none of which has any plots. There is no link to
      'plot' when the section mentions the plot command. Searching for 'plot'
      is ineffective, because the word is used so many times. At this point, I
      hit back a few times and go to the official gnuplot quick reference.
   6) After looking all over for an example with different points, I find, on
      the bottom of page 4, the following example:

          plot "data" with points 1 3

      My intuition says this is the command I want. Indeed, it is.

In all fairness, I went back and finally found the REAL table of contents,
which is above the 'gnuplot' table of contents and below the list of
contributors (in small text, with no title). I clicked Commands, then 'plot',
where it describes the plot command. Because I already knew I was looking for
'with', I clicked that. There it was. Yet, *still*, nowhere does it say 'to
plot with circles, use this style.' I had to do trial and error to find the
right symbol.

I understand that usability is hard. I am mailing the list with my experiences
in the hopes that gnuplot can improve, and the next person's experience will be
better. My father gave up on Gnuplot ages ago because he encountered similar
frustrations to my own; however, he silently moved on rather than engaging the
community.
 
> >gnuplot> plot 'file1' with points 4 3
> >gnuplot> plot 'file2' with points 1 4
> 
> The problem with both your suggestions:
> 
> >gnuplot> plot 'file1' with points 'red squares'
> >gnuplot> plot 'file2' with points 'blue crosses'
> >gnuplot> plot 'file1' with points 'orange octagons'
> [...]
> >The symbols are:
> >        's' : square
> >        'o' : circle
> >        '^' : triangle up
> 
> is the same: they completely ignore one central design principle of 
> gnuplot: script compatibility across terminal drivers.  Your proposal
> fails to address the question what gnuplot should do with a plot script 
> that requests some point symbol the current driver simply can't generate.

I address this in my other follow-up. I would also like to mention that I feel
when choices of symbol types are deliberate, it is unfortunate that gnuplot
does not guarentee the same symbols across terminals.

Gnuplot should simply make an expansive list of Standard Gnuplot Symbols, a
subset of which every terminal is required to implement.

Cheers,
Keir

Re: Suggestion to improve usability of plot command

[Keir M. <ke...@cs...>]

On Sat, Oct 07, 2006 at 02:55:40PM -0400, Daniel J Sebald wrote:
> Hans-Bernhard Br?ker wrote:
> 
> >>gnuplot> plot 'file1' with points 'red squares'
> >>gnuplot> plot 'file2' with points 'blue crosses'
> >>gnuplot> plot 'file1' with points 'orange octagons'
> 
> Call this the Lucky Charms design principle.  (I probably used that joke 
> already... for which many of you likely don't know that Lucky Charms is a 
> brand of cereal.)
> 
> I'm actually kind of partial to this syntax.  Could maybe even change it to 
> read like
> 
> gnuplot> plot 'file1' with red square points
> 
> The one problem is that to describe some of these symbols can get lengthy, 
> e.g., "filled square" vs. "empty square".  However, we could limit the 
> number of symbol names to be six or eight, i.e., just "square" (could get 
> the filled square using the numbers).

I actually wrote this as my proposed syntax first, but decided it would be too
controversial because 'red' could be a variable.

As long as a condensed syntax is available, then lengthy names are just fine.
When not excessively verbose, syntax which needs no documentation good.
 
> >>The symbols are:
> >>       's' : square
> >>       'o' : circle
> >>       '^' : triangle up
> 
> or this.  Not as easy to remember, but condensed syntax.

I became firmly convinced, when I heard a story from my friend David about
MATLAB plotting syntax (he is an IDL user): the first time he encountered it, a
friend of his was plotting some data in MATLAB. He said that at the end of the
plot command was this mysterious 'r.', yet when the plot came up he instantly
understood the syntax: red dots! Apparently this happened years ago, yet he
still remembers the syntax today. (And never uses MATLAB)
 
> >is the same: they completely ignore one central design principle of 
> >gnuplot: script compatibility across terminal drivers.  Your proposal
> >fails to address the question what gnuplot should do with a plot script 
> >that requests some point symbol the current driver simply can't generate.
> 
> The driver would map to another symbol and issue a warning.  (And we could 
> write an algorithm so that it isn't mapped to an already used symbol 
> number.)

Yes. I believe in keeping easy things easy, and hard things possible.
 
> I keep a file on my computer with such numbers:
> 
> Symbol translation for Octave to "pslatex" terminal:
> 
> 1 - plus
> 2 - x
> 3 - asterisk
> 4 - open square
> 5 - solid square
> 6 - open circle
> 7 - solid circle
> 8 - open triangle
> 9 - solid triangle
> 
> I don't know if the problem is so much the use of numbers for me.  The 
> problem is the fact that the numbers don't produce the same symbols across 
> drivers.  Why couldn't those be mapped to be similar symbols?  It is very 
> frustrating to create a plot on the screen, then save it as PostScript to 
> find the symbols are different.  In that sense, I'd say gnuplot isn't 
> script compatible.

I think this is a pretty convincing argument to adopt the new syntax, or
something like it; it sounds as though the existing system is actually worse!

Besides -- this is 2006. Which terminal that is frequently used by the majority
of users can't support all of the symbol types? I'm pretty baffled.  Besides,
if a user is writing a gnuplot script with color arguments, they can hardly
expect it to look amazing in black and white or grayscale.  I understand not
all terminals have colors, but there's no reason we can't do something
reasonable in the face of black and white. If they user wants gorgeous plots
that work in black and white and color, then they can use the old numeric
style.

Cheers,
Keir

Re: Suggestion to improve usability of plot command

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

Hans-Bernhard Br=F6ker wrote:

>>gnuplot> plot 'file1' with points 'red squares'
>>gnuplot> plot 'file2' with points 'blue crosses'
>>gnuplot> plot 'file1' with points 'orange octagons'

Call this the Lucky Charms design principle.  (I probably used that joke =
already... for which many of you likely don't know that Lucky Charms is a=
 brand of cereal.)

I'm actually kind of partial to this syntax.  Could maybe even change it =
to read like

gnuplot> plot 'file1' with red square points

The one problem is that to describe some of these symbols can get lengthy=
, e.g., "filled square" vs. "empty square".  However, we could limit the =
number of symbol names to be six or eight, i.e., just "square" (could get=
 the filled square using the numbers).

>=20
> [...]
>=20
>>The symbols are:
>>        's' : square
>>        'o' : circle
>>        '^' : triangle up

or this.  Not as easy to remember, but condensed syntax.


> is the same: they completely ignore one central design principle of=20
> gnuplot: script compatibility across terminal drivers.  Your proposal
> fails to address the question what gnuplot should do with a plot script=
=20
> that requests some point symbol the current driver simply can't generat=
e.

The driver would map to another symbol and issue a warning.  (And we coul=
d write an algorithm so that it isn't mapped to an already used symbol nu=
mber.)

I keep a file on my computer with such numbers:

Symbol translation for Octave to "pslatex" terminal:

1 - plus
2 - x
3 - asterisk
4 - open square
5 - solid square
6 - open circle
7 - solid circle
8 - open triangle
9 - solid triangle

I don't know if the problem is so much the use of numbers for me.  The pr=
oblem is the fact that the numbers don't produce the same symbols across =
drivers.  Why couldn't those be mapped to be similar symbols?  It is very=
 frustrating to create a plot on the screen, then save it as PostScript t=
o find the symbols are different.  In that sense, I'd say gnuplot isn't s=
cript compatible.

Dan

Re: Suggestion to improve usability of plot command

[<br...@ph...>]

Keir Mierle wrote:
> I have a simple suggestion to improve the usability of the plot command.
> Currently, I am not a huge fan of the way point styles are specified; 

Not very surprisingly --- the syntax you use has never actually been 
documented, and has been deprecated for a *long* time now.  The current 
syntax, while still oriented towards numbers, is a lot clearer than

> gnuplot> plot 'file1' with points 4 3
> gnuplot> plot 'file2' with points 1 4

The problem with both your suggestions:

> gnuplot> plot 'file1' with points 'red squares'
> gnuplot> plot 'file2' with points 'blue crosses'
> gnuplot> plot 'file1' with points 'orange octagons'
[...]
> The symbols are:
>         's' : square
>         'o' : circle
>         '^' : triangle up

is the same: they completely ignore one central design principle of 
gnuplot: script compatibility across terminal drivers.  Your proposal
fails to address the question what gnuplot should do with a plot script 
that requests some point symbol the current driver simply can't generate.

Re: Gentlemen, start your engines...

[<br...@ph...>]

Ethan Merritt wrote:

> What is the correct way to have ./configure figure this out?

There are two possibilities:

1) one that goes very much against the grain of what autoconf was 
designed for: a switch/case on (part of) the canonical platform name, as 
figured out by config.guess.

2) the fully autoconf-ish approach: check whether -ieee improves the 
behaviour of a test program, by compiling and running it twice.

3) the middle way: compile a test souce with an #ifdef __ALPHA__  or so, 
and if it's there, add -ieee to the CFLAGS.

For an examples of technique 3), see the existing macros in m4/*.m4.

Re: Gentlemen, start your engines...

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

Ethan Merritt wrote:
> On Friday 06 October 2006 04:05 pm, Ethan Merritt wrote:
>=20
>>On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote:
>>
>>>Everybody should check out a working copy of the branch, and test
>>>that it works as expected, on as many platforms as you can.
>>
>>Digital Unix 4.0D (DECC compiler)
>> - Builds OK, but ...
>> - triggers floating exception in surface1.dem
>>	(Bug #1572268)
>> - triggers floating exception in image.dem when trying to
>>   read deliberately wrong-endian binary data
>>	(maybe we should remove this demo)
>=20
>=20
> Both of these can be cured by adding "-ieee" to the compiler flags.

Interesting.  It probably adds a special handler or limits the exceptions=
 to just those 5 IEEE apparently defines:

http://www.unet.univie.ac.at/aix/aixprggd/genprogc/floating-point_except.=
htm

> What is the correct way to have ./configure figure this out?

DEC bought Apollo at some point.  Is this compilation one with "APOLLO" d=
efined?  Then maybe look for APOLLO in configure.in and at that point add=
 the -ieee to the flags.

Dan

Re: Gentlemen, start your engines...

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

On Friday 06 October 2006 04:05 pm, Ethan Merritt wrote:
> On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote:
> > Everybody should check out a working copy of the branch, and test
> > that it works as expected, on as many platforms as you can.
>
> Digital Unix 4.0D (DECC compiler)
>  - Builds OK, but ...
>  - triggers floating exception in surface1.dem
> 	(Bug #1572268)
>  - triggers floating exception in image.dem when trying to
>    read deliberately wrong-endian binary data
> 	(maybe we should remove this demo)

Both of these can be cured by adding "-ieee" to the compiler flags. =20

What is the correct way to have ./configure figure this out?



=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Gentlemen, start your engines...

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

Ethan Merritt wrote:
> On Friday 06 October 2006 04:36 pm, Daniel J Sebald wrote:
> 
>>Ethan Merritt wrote:
>>
>>>Digital Unix 4.0D (DECC compiler)
>>> - Builds OK, but ...
>>> - triggers floating exception in surface1.dem
>>>	(Bug #1572268)
>>> - triggers floating exception in image.dem when trying to
>>>   read deliberately wrong-endian binary data
>>>	(maybe we should remove this demo)
>>
>>What happens on the DEC with
>>
>>set samples 101
>>plot 1/x
> 
> 
> Nothing special.  The issue is not divide-by-zero or underflow.
> The wrong-endian exception is from trying to do anything at all
> with a  bit pattern that is not a valid floating point number.

I'm just wondering how generally the DEC behaves on an FPE.  If it happens that the FPE occurs inside

	return df_readbinary(v, max);

at the point of constructing the floating point value, we may be able to trap that and map the status to "undefined".

Dan