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

Re: postscript monochrome and specified color

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

On Wednesday 02 August 2006 11:05 pm, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > 
> > You ask for blue, you get blue.  
> > If you don't want blue, don't ask for blue.
> 
> But I asked for monochrome too.  Why can't I have that instead?

If you ask for default dashed lines via "set term post dashed"
that doesn't stop you from explicitly drawing a solid line.

If you ask for a small default font via "set term post font 'Times' 4"
that doesn't stop you from explicitly writing labels in a larger font.

If you ask for default thick lines via 'set term post lw 5'
that doesn't stop you from explicitly drawing a thin line.

So if you ask for default black lines via 'set term post mono',
why should it stop you from explicitly drawing a blue line?

The terminal options are defaults, not restrictions.

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

Re: postscript monochrome and specified color

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

Ethan A Merritt wrote:
> On Wednesday 02 August 2006 10:45 pm, Daniel J Sebald wrote:
> 
>>set term postscript monochrome eps
>>plot x with points lc rgb "blue"
>>
>>will produce a plot that still has blue points.
> 
> 
> You ask for blue, you get blue.  
> If you don't want blue, don't ask for blue.

But I asked for monochrome too.  Why can't I have that instead?

Dan

Re: postscript monochrome and specified color

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

On Wednesday 02 August 2006 10:45 pm, Daniel J Sebald wrote:
> 
> set term postscript monochrome eps
> plot x with points lc rgb "blue"
> 
> will produce a plot that still has blue points.

You ask for blue, you get blue.  
If you don't want blue, don't ask for blue.

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

postscript monochrome and specified color

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

Is there a reason that "monochrome" can't or shouldn't cast objects specified with explicit color to a shade of gray?

" The option `color` enables color, while `monochrome` prefers black and white",\
" drawing elements. Further, `monochrome` uses gray `palette` but it does not",\
" change color of objects specified with an explicit `colorspec`."\

For example,

plot x with points lc rgb "blue"
set term postscript monochrome eps
set output 'foo.eps'
replot
set output

will produce a plot that still has blue points.

Dan

Re: -persist and the wxWidgets terminal, continued

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

Dave Denholm wrote:
> Timoth=E9e Lecomte <tim...@en...> writes:
>
>  =20
>>>>> gnuplot can fork(), then allow the parent to exit, leaving the chil=
d
>>>>> continuing to run the same code in exactly the same state, but
>>>>> detached.
>>>>>          =20
>
>
>  =20
>>>> and because exiting
>>>> the parent would close file and socket descriptors, thus closing the
>>>> connection to the X server.
>>>>
>>>>        =20
>>> No, the child inherits the open files.
>>>
>>>      =20
>> It does, but when the parent calls exit(), the corresponding files are
>> closed. There is a workaround : _exit(), but again, I think it becomes
>> too complicated and less portable.
>>    =20
>
> exit() can cause problems, but it doesn't close the files and
> sockets. Or at least, it closes the parent's handles, but the child's
> handles mean the underlying instance remains open.
>
> Parent exit() does cause stdio to get cleaned up, which can confuse
> things.
>
> I rather assumed that as soon as we started discussing fork() we were
> in a unix-only scenario.
>  =20
The unix-only was my assumption too. As far as the exit()/_exit() stuff=20
is concerned, here is a quote from the gtk+ FAQ :

"5.5. Why does this strange 'x io error' occur when I fork() in my GTK+=20
app? [GTK 2.x]

This is not really a GTK+ problem, and the problem is not related to=20
fork() either. If the 'x io error' occurs then you probably use the=20
exit() function in order to exit from the child process.

When GDK opens an X display, it creates a socket file descriptor. When=20
you use the exit() function, you implicitly close all the open file=20
descriptors, and the underlying X library really doesn't like this.

The right function to use here is _exit()."

According to 'man 2 exit', the only difference between exit() and=20
_exit() is that the former executes all the functions registered in=20
atexit(), whereas the former doesn't. I guess the Xlib automatically=20
registers one of those, and get confused when exit() is used.

Then, my conclusion is that fork() could indeed be used, but I still=20
wonder if it's worth coding it.


>>> One other option would always be to immediately fork, but keep the
>>> parent around as a dummy process (just so that the original process
>>> knows it's still active). So all the work would happen in the child.
>>> In effect, code it as if you always detach, and then keep the parent
>>> alive as a workaround to stop the original process thinking the child
>>> has exited until the child chooses to detach.
>>>
>>>      =20
>> I wonder what happens regarding the command line then.
>>
>>    =20
>
> Shouldn't really notice anything happening. Both parent and child have
> stdin open, (or maybe parent closes it), but only child is actually
> reading from it, and so it doesn't matter.
>
> (After all, if you launch gnuplot interactively from a shell, the
> shell still has the stdin stream open. But it just isn't reading from
> it.)
>  =20
Thank you very much for your explanations ! It's nice to understand=20
fork() a little bit more.

Best regards,

Timoth=E9e

Re: -persist and the wxWidgets terminal, continued

[Dave D. <dde...@es...>]

Timoth=E9e Lecomte <tim...@en...> writes:

>>>>>
>>>> gnuplot can fork(), then allow the parent to exit, leaving the child
>>>> continuing to run the same code in exactly the same state, but
>>>> detached.


>>> and because exiting
>>> the parent would close file and socket descriptors, thus closing the
>>> connection to the X server.
>>>
>>
>> No, the child inherits the open files.
>>
> It does, but when the parent calls exit(), the corresponding files are
> closed. There is a workaround : _exit(), but again, I think it becomes
> too complicated and less portable.
>>

exit() can cause problems, but it doesn't close the files and
sockets. Or at least, it closes the parent's handles, but the child's
handles mean the underlying instance remains open.

Parent exit() does cause stdio to get cleaned up, which can confuse
things.

I rather assumed that as soon as we started discussing fork() we were
in a unix-only scenario.

>>> A workaround would be to close the GUI
>>> thread and the windows before the fork() and to open them again in the
>>> child, but I'm not sure maxima users would appreciate to see their
>>> window disappearing and reappearing...
>>>
>>>
>>
>>
>> One other option would always be to immediately fork, but keep the
>> parent around as a dummy process (just so that the original process
>> knows it's still active). So all the work would happen in the child.
>> In effect, code it as if you always detach, and then keep the parent
>> alive as a workaround to stop the original process thinking the child
>> has exited until the child chooses to detach.
>>
> I wonder what happens regarding the command line then.
>

Shouldn't really notice anything happening. Both parent and child have
stdin open, (or maybe parent closes it), but only child is actually
reading from it, and so it doesn't matter.

(After all, if you launch gnuplot interactively from a shell, the
shell still has the stdin stream open. But it just isn't reading from
it.)

dd
--=20
Dave Denholm              <dde...@es...>       http://www.esmertec=
.com

Re: -persist and the wxWidgets terminal, continued

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

Dave Denholm wrote:
> Timoth=E9e Lecomte <tim...@en...> writes:
>
>  =20
>> Dave Denholm wrote:
>>    =20
>>>> - mimic a 'bg' to gnuplot. Well, I don't know how to do that from
>>>> gnuplot, and I doubt it will actually work : since gnuplot's
>>>> process is still running, octave still waits for it.
>>>>
>>>> Do any of you have a miraculous idea, or should I report that to
>>>> the octave developers as I did for maxima ?
>>>>
>>>>
>>>>        =20
>>> gnuplot can fork(), then allow the parent to exit, leaving the child
>>> continuing to run the same code in exactly the same state, but
>>> detached.
>>>
>>>      =20
>> This won't work in my case, because the terminal is multithreaded and
>> fork() has undetermined behaviour with threads,
>>    =20
>
> Not really... you can install fork handlers (assuming pthreads). But
> yes, it all becomes horribly complicated. See pthread_atfork()
>  =20
Well, you're right, especially when you say "horribly complicated" ;)
>
>  =20
>> and because exiting
>> the parent would close file and socket descriptors, thus closing the
>> connection to the X server.
>>    =20
>
> No, the child inherits the open files.
>  =20
It does, but when the parent calls exit(), the corresponding files are=20
closed. There is a workaround : _exit(), but again, I think it becomes=20
too complicated and less portable.
>  =20
>> A workaround would be to close the GUI
>> thread and the windows before the fork() and to open them again in the
>> child, but I'm not sure maxima users would appreciate to see their
>> window disappearing and reappearing...
>>
>>    =20
>
>
> One other option would always be to immediately fork, but keep the
> parent around as a dummy process (just so that the original process
> knows it's still active). So all the work would happen in the child.
> In effect, code it as if you always detach, and then keep the parent
> alive as a workaround to stop the original process thinking the child
> has exited until the child chooses to detach.
>  =20
I wonder what happens regarding the command line then.

Anyway, I would *really* prefer not to have to play with fork() just to=20
satisfy a particular use case that is not written word for word=20
anywhere. I am sure the maxima folks will find a nice workaround=20
(there's already one workaround: defining a simple shell wrapper that=20
launches gnuplot in the background) (I would be glad to help them if=20
only it wouldn't be coded in lisp...).

Timoth=E9e

Reword GIF section of README.1st

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

Hi,

The notes about GIF output in README.1st are outdated. Attached is a=20
patch as per my understanding, but I would like to see it confirmed=20
before committing. Please tell me if it is ok.

As far as the ongoing process towards 4.2 is concerned, we still have to=20
update the copyrights years of all files, increment VERSION, and review=20
the couple of doc files (README, INSTALL, etc).

Best regards,

Timoth=C3=A9e

Re: -persist and the wxWidgets terminal, continued

[Dave D. <dde...@es...>]

Timoth=E9e Lecomte <tim...@en...> writes:

> Dave Denholm wrote:
>>
>>> - mimic a 'bg' to gnuplot. Well, I don't know how to do that from
>>> gnuplot, and I doubt it will actually work : since gnuplot's
>>> process is still running, octave still waits for it.
>>>
>>> Do any of you have a miraculous idea, or should I report that to
>>> the octave developers as I did for maxima ?
>>>
>>>
>>
>> gnuplot can fork(), then allow the parent to exit, leaving the child
>> continuing to run the same code in exactly the same state, but
>> detached.
>>
> This won't work in my case, because the terminal is multithreaded and
> fork() has undetermined behaviour with threads,

Not really... you can install fork handlers (assuming pthreads). But
yes, it all becomes horribly complicated. See pthread_atfork()


> and because exiting
> the parent would close file and socket descriptors, thus closing the
> connection to the X server.

No, the child inherits the open files.

> A workaround would be to close the GUI
> thread and the windows before the fork() and to open them again in the
> child, but I'm not sure maxima users would appreciate to see their
> window disappearing and reappearing...
>


One other option would always be to immediately fork, but keep the
parent around as a dummy process (just so that the original process
knows it's still active). So all the work would happen in the child.
In effect, code it as if you always detach, and then keep the parent
alive as a workaround to stop the original process thinking the child
has exited until the child chooses to detach.

dd
--=20
Dave Denholm              <dde...@es...>       http://www.esmertec=
.com

Re: problem building latest cvs snapshot

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

Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
>
>>> checking for CAIRO... Package cairo was not found in the pkg-config=20
>>> search path.Perhaps you should add the directory containing `cairo.pc=
'
>>> to the PKG_CONFIG_PATH environment variable
>>> No package 'cairo' found
>>>  =20
>>
>>
>> The above messages are the defaults provided by pkg-config.
>
> Oh, sorry.  Why is configure so terse in one instance, and then here=20
> gets so wordy with stuff like "Perhaps you should"?
Hey, that's how humans work, sometimes wordy, sometimes terse ;-) (it=20
reminds me of "Cathedrals, Bazaars and the Town Council" from Alan Cox).

>
>>
>>> And this one:
>>>
>>> checking for PANGO... Requested 'pango >=3D 1.10' but version of Pang=
o=20
>>> is 1.6.0
>>>
>>> could be:
>>>
>>> checking for PANGO... found 1.6.0, require >=3D 1.10
>>>  =20
>>
>>
>> To me, that's just the same.
>
> Right, but it is shorter and fits on one line rather than wrapping at=20
> 80 chars.  (Is this another "configure issued" default warning?)
Yes, another pkg-config defaults.


> I'd think at the bottom in the list of what is included might be better=
.=20
Let's add to the post-4.2 list : "rework final report from ./configure,=20
with both the _brief_ list of compiled-in features and the _brief_ list=20
of not-compiled in features, with the corresponding requirements".

Best regards,

Timoth=E9e

Re: problem building latest cvs snapshot

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

> Let them stay as they are.

OK.

> After 200 lines of semi-intelligible output from the
> configure script we have no control over, why quibble about
> warnings that actually contain useful information?

Humid weather... err!

Dan

Re: problem building latest cvs snapshot

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

Timoth=E9e Lecomte wrote:

>> checking for CAIRO... Package cairo was not found in the pkg-config=20
>> search path.Perhaps you should add the directory containing `cairo.pc'
>> to the PKG_CONFIG_PATH environment variable
>> No package 'cairo' found
>>  =20
>=20
>=20
> The above messages are the defaults provided by pkg-config.

Oh, sorry.  Why is configure so terse in one instance, and then here gets=
 so wordy with stuff like "Perhaps you should"?


>> configure: WARNING: Cairo can't be found. The wxWidgets terminal will=20
>> not be compiled.
>>  =20
>=20
>=20
> I wrote this one, and I am willing to improve the message if you think=20
> we can do better. For example, I can replace "WARNING" by "NOTE".
>=20
>> The only real bit of info in the above message is "Perhaps you should=20
>> add the directory containing `cairo.pc'
>> to the PKG_CONFIG_PATH environment variable" and even that is wordy. =20
>> And, once that is stated it becomes redundant information when it is=20
>> displayed several more times later.
>>  =20
>=20
> It is not redundant as different packages are concerned.

Same bloated sentence with one word different.  High entropy, low informa=
tion content.


>=20
>> And this one:
>>
>> checking for PANGO... Requested 'pango >=3D 1.10' but version of Pango=
=20
>> is 1.6.0
>>
>> could be:
>>
>> checking for PANGO... found 1.6.0, require >=3D 1.10
>>  =20
>=20
>=20
> To me, that's just the same.

Right, but it is shorter and fits on one line rather than wrapping at 80 =
chars.  (Is this another "configure issued" default warning?)


> I can reword that into "No valid Pango package was found. The wxWidgets=
=20
> terminal will not be compiled." if you prefer.

I'm suggesting to be more brief and include info at appropriate locations=
.  Having too much extraneous info can sometimes be just as big a problem=
 as not enough info.

I just think that at the point where configure checks for packages and ca=
n't find them it isn't necessary to say what the ramification of that is =
just yet.  I'd think at the bottom in the list of what is included might =
be better.

Dan

Re: problem building latest cvs snapshot

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

Timoth=E9e Lecomte wrote:
> James R. Van Zandt wrote:
>=20
>> Daniel J Sebald <dan...@ie...> wrote:
>>
>> =20
>>
>>>   4) Could the following warnings be removed?
>>>
>>>   checking for CAIRO... Package cairo was not found in the
>>>   pkg-config search path.
>>>   Perhaps you should add the directory containing `cairo.pc' to the
>>>   PKG_CONFIG_PATH environment variable
>>>   No package 'cairo' found
>>>   configure: WARNING: Cairo can't be found. The wxWidgets terminal
>>>   will not be compiled.
>>>    =20
>>
>> ...
>> =20
>>
>>>   Isn't it the job of the auto-build tools to sort out what should
>>>   and shouldn't be built?  This isn't a valid situation for warnings
>>>   from my perspective.
>>>    =20
>>
>>
>> I for one appreciate these warnings.  If I am interested in the
>> missing functionality, they tell me what other software I should look
>> for.
>>             - Jim Van Zandt
>>  =20
>=20
> Daniel, would it satisfy you if I replace the "WARNING" by "NOTE" ?

Not really.  In my opinion, be more terse.  Here there are three warnings=
:

configure: WARNING: Pango can't be found. The wxWidgets terminal will not=
 be compiled.
configure: WARNING: Cairo can't be found. The wxWidgets terminal will not=
 be compiled.
configure: WARNING: Cairo rendering support for Pango can't be found. The=
 wxWidgets terminal will not be compiled.

stating wxWidgets terminal will not be included.  Too wordy and redundant.

Ethan, what kind of warning messages are given when JPEG, PNG, etc. aren'=
t available?  Can this be summarized at the bottom of ./configure along w=
ith all the other items listed?  E.g.,

Do not build wxWidgets (requires Cairo, Pango or CairoPango)

Dan

Re: problem building latest cvs snapshot

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

On Sunday 30 July 2006 02:54 pm, Timoth=E9e Lecomte wrote:
> Daniel, would it satisfy you if I replace the "WARNING" by "NOTE" ?

Let them stay as they are.
After 200 lines of semi-intelligible output from the
configure script we have no control over, why quibble about
warnings that actually contain useful information?


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

Re: problem building latest cvs snapshot

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

Daniel J Sebald wrote:
> James R. Van Zandt wrote:
>  =20
>>
>> I for one appreciate these warnings.  If I am interested in the
>> missing functionality, they tell me what other software I should look
>> for.=20
>>    =20
>
> Yes, but the key word there being "if".  I mean, why can't this:
>
> checking for CAIRO... Package cairo was not found in the pkg-config sea=
rch path.Perhaps you should add the directory containing `cairo.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'cairo' found
>  =20

The above messages are the defaults provided by pkg-config. If we change=20
them, we lose the ability to exactly know why it doesn't find the=20
package. See your own example below about the versions required.

> configure: WARNING: Cairo can't be found. The wxWidgets terminal will n=
ot be compiled.
>  =20

I wrote this one, and I am willing to improve the message if you think=20
we can do better. For example, I can replace "WARNING" by "NOTE".

> The only real bit of info in the above message is "Perhaps you should a=
dd the directory containing `cairo.pc'
> to the PKG_CONFIG_PATH environment variable" and even that is wordy.  A=
nd, once that is stated it becomes redundant information when it is displ=
ayed several more times later.
>  =20
It is not redundant as different packages are concerned.
> And this one:
>
> checking for PANGO... Requested 'pango >=3D 1.10' but version of Pango =
is 1.6.0
>
> could be:
>
> checking for PANGO... found 1.6.0, require >=3D 1.10
>  =20

To me, that's just the same.

> configure: WARNING: Pango can't be found. The wxWidgets terminal will n=
ot be compiled.
>
> which in fact seems like a conflicting report to me.  Pango WAS found, =
it just isn't a recent enough version.
>  =20

I can reword that into "No valid Pango package was found. The wxWidgets=20
terminal will not be compiled." if you prefer.

Best regards,

TImoth=E9e

Re: problem building latest cvs snapshot

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

James R. Van Zandt wrote:
> Daniel J Sebald <dan...@ie...> wrote:
> 
> 
>>  4) Could the following warnings be removed?
>>
>>  checking for CAIRO... Package cairo was not found in the
>>  pkg-config search path.
>>  Perhaps you should add the directory containing `cairo.pc' to the
>>  PKG_CONFIG_PATH environment variable
>>  No package 'cairo' found
>>  configure: WARNING: Cairo can't be found. The wxWidgets terminal
>>  will not be compiled.
> 
> ...
> 
>>  Isn't it the job of the auto-build tools to sort out what should
>>  and shouldn't be built?  This isn't a valid situation for warnings
>>  from my perspective.
> 
> 
> I for one appreciate these warnings.  If I am interested in the
> missing functionality, they tell me what other software I should look
> for. 

Yes, but the key word there being "if".  I mean, why can't this:

checking for CAIRO... Package cairo was not found in the pkg-config search path.Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cairo' found
configure: WARNING: Cairo can't be found. The wxWidgets terminal will not be compiled.

be summarized as:

checking for CAIRO... no

As with the several other cases where "no" comes up in the ./configure operation, logic tells me that configure could not find the package and therefore it will not be included in the compilation.  Why does there need to be a WARNING to tell me that?  The only real bit of info in the above message is "Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable" and even that is wordy.  And, once that is stated it becomes redundant information when it is displayed several more times later.

And this one:

checking for PANGO... Requested 'pango >= 1.10' but version of Pango is 1.6.0

could be:

checking for PANGO... found 1.6.0, require >= 1.10

Most people understand the ramification of that.  We don't then need to know:

configure: WARNING: Pango can't be found. The wxWidgets terminal will not be compiled.

which in fact seems like a conflicting report to me.  Pango WAS found, it just isn't a recent enough version.

Perhaps there should be a verbose mode for configure.

Dan

Re: problem building latest cvs snapshot

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

James R. Van Zandt wrote:
> Daniel J Sebald <dan...@ie...> wrote:
>
>  =20
>>   4) Could the following warnings be removed?
>>
>>   checking for CAIRO... Package cairo was not found in the
>>   pkg-config search path.
>>   Perhaps you should add the directory containing `cairo.pc' to the
>>   PKG_CONFIG_PATH environment variable
>>   No package 'cairo' found
>>   configure: WARNING: Cairo can't be found. The wxWidgets terminal
>>   will not be compiled.
>>    =20
> ...
>  =20
>>   Isn't it the job of the auto-build tools to sort out what should
>>   and shouldn't be built?  This isn't a valid situation for warnings
>>   from my perspective.
>>    =20
>
> I for one appreciate these warnings.  If I am interested in the
> missing functionality, they tell me what other software I should look
> for.=20
>
>             - Jim Van Zandt
>  =20
Daniel, would it satisfy you if I replace the "WARNING" by "NOTE" ?

Best regards,

TImoth=E9e

Re: problem building latest cvs snapshot

[James R. V. Z. <jr...@co...>]

Daniel J Sebald <dan...@ie...> wrote:

>   4) Could the following warnings be removed?
>
>   checking for CAIRO... Package cairo was not found in the
>   pkg-config search path.
>   Perhaps you should add the directory containing `cairo.pc' to the
>   PKG_CONFIG_PATH environment variable
>   No package 'cairo' found
>   configure: WARNING: Cairo can't be found. The wxWidgets terminal
>   will not be compiled.
...
>
>   Isn't it the job of the auto-build tools to sort out what should
>   and shouldn't be built?  This isn't a valid situation for warnings
>   from my perspective.

I for one appreciate these warnings.  If I am interested in the
missing functionality, they tell me what other software I should look
for. 

            - Jim Van Zandt
     

Formatting patch

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

Patch for a gnuplot.doc line that extends past 80 chars.

Dan

Re: problem building latest cvs snapshot

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

Daniel J Sebald wrote:

> 1) The first thing that strikes me is that I get the instruction
> "See 'help x11' for more details".  However, how do I see the help
>when I can't get to the program command line?  So, this really
>shouldn't be a critical error in my opinion.  Yes, the x11 driver
> should register an error, but in a graceful way from the command line.
> 
> 2) As for gnuplot attempting to find gnuplot_x11 at start up.
>  Perhaps this should be delayed to the point of first trying to create a plot.

I put a patch on SourceForge that will remove X11_init() from X11_options().  This solves the above problem.  If gnuplot_x11 is missing, the command line behaves as:

Terminal type set to 'x11'
gnuplot> plot x
Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
Exec failed: No such file or directory
See 'help x11' for more details

Note that the exit is apparently re-routed back to the command line at this point in the program.  So, after I hit return, then the command line prompt comes back.  It isn't the as graceful as it could be, but I think it is good enough for the situation it addresses.

What the ramification of removing that X11_init() is I'm not sure.  Perhaps Ethan has a better feel for that.  There aren't any font characteristics or something that gnuplot_x11 is needed for inside X11_options(), is there?

Dan

Re: problem building latest cvs snapshot

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

Ethan Merritt wrote:

> We can continue to discuss whether it is a mistake to initialize
> x11 on entry if it is the default terminal.

Well, it sort of is (unless in some initialization file the user specifies that the desired terminal is x11).

I've just seen another bug in the SourceForge list:

 [ 997481 ] [autoconf] name transformation of gnuplot_x11

which is closely related to this issue.  We should probably clear this up and get rid of this bug report.  I've just tested as the bug reporter instructed.  After build is the X11 driver:

[gnuplot]# ls /usr/local/libexec/gnuplot/4.1
gnuplot_x11-suffix  gnuplot_x11_tempmovedhere

[gnuplot]# gnuplot
Expected X11 driver: /usr/local/libexec/gnuplot/4.1/gnuplot_x11
Exec failed: No such file or directory
See 'help x11' for more details

1) The first thing that strikes me is that I get the instruction "See 'help x11' for more details".  However, how do I see the help when I can't get to the program command line?  So, this really shouldn't be a critical error in my opinion.  Yes, the x11 driver should register an error, but in a graceful way from the command line.

2) As for gnuplot attempting to find gnuplot_x11 at start up.  Perhaps this should be delayed to the point of first trying to create a plot.  Is that possible?  Keep in mind, if the error is more graceful as in (1) then this really isn't a critical issue anymore as gnuplot wouldn't critically fail.  There would be the error message and the user could simply change to a different terminal driver.  But still, not having the error message until absolutely necessary would be nice.

3) As to the original bug report, so long as someone is looking at this, would the patch I put on SourceForge suffice?  If one does something like

./prepare
./configure --program-prefix=PRE --program-suffix=SUF
make install

The files PREgnuplotSUF and PREgnuplot_x11SUF will be created.

In the bug report, Hans states that adding the suffix to gnuplot-x11 isn't necessary.  However, I'd argue it is.  The person who uses "program-suffix" is someone who might create a special version of the program that has a recent patch or something.  If that patch effected gplt_x11.c then it would be nice to have the two different versions of gnuplot_x11 and gnuplot_x11-suffix.  E.g., someone wants the most recent official release and one with a great new feature, "gnuplot" and "gnuplotspif".

4) Could the following warnings be removed?

checking for CAIRO... Package cairo was not found in the pkg-config search path.Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cairo' found
configure: WARNING: Cairo can't be found. The wxWidgets terminal will not be compiled.
checking for PANGO... Requested 'pango >= 1.10' but version of Pango is 1.6.0
configure: WARNING: Pango can't be found. The wxWidgets terminal will not be compiled.
checking for PANGOCAIRO... Package pangocairo was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangocairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pangocairo' found
configure: WARNING: Cairo rendering support for Pango can't be found. The wxWidgets terminal will not be compiled.

Isn't it the job of the auto-build tools to sort out what should and shouldn't be built?  This isn't a valid situation for warnings from my perspective.

Dan

Re: Version 4.2 - ringing the bell that signals the final lap

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

Ethan A Merritt wrote:
> So in my judgment we are essentially ready for a code freeze and the st=
art
> of a 4.2 branch on CVS from which to build a candidate release package.
>
> Conveniently for me, I'm leaving town for a week and expect little usef=
ul
> net access.  What a great thing it would be if I return to find that yo=
u
> guys have taken care of the versioning tags, code branch, and final
> updates to the docs while I'm gone :-)
>  =20
As far as I am concerned, I went through the "news" section of=20
gnuplot.doc and completed it. I think the docs can be considered ok for 4=
.2.

The only remaining things in my opinion before the branching are:
-wait for the Japanese translation to be in sync,
-increment the VERSION file.

Best regards,

Timoth=E9e

Re: Doc : "ai driver deprecated"

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

On Friday 28 July 2006 10:41 pm, Timoth=C3=A9e Lecomte wrote:
> Ethan A Merritt wrote:
> > We don't normally have entries for non-existent terminals in the help s=
ection.
> >  =20
> The terminal is still there, compiled in unconditionally.

Hmm. You're right. =20
I thought we had decided to remove it.
Let's at least make it a configuration option, with the default to not incl=
ude it.
It has not been maintained for a long time.

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

Re: Doc : "ai driver deprecated"

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

Ethan A Merritt wrote:
> On Friday 28 July 2006 08:41 pm, Timoth=C3=A9e Lecomte wrote:
> "Adobe Illustrator (ai) driver deprecated".
>  =20
>> What does it mean in practise ?
>> Shouldn't this message rather be in "help ai" instead of the news sect=
ion ?
>>    =20
>
> We don't normally have entries for non-existent terminals in the help s=
ection.
>  =20
The terminal is still there, compiled in unconditionally.
> I think NEWS or "Changes since 4.0" are the right place for such a warn=
ing.
>  =20
Ok.
>  =20
>> I propose to write this, taken from Harald Harders on this list=20
>> (http://article.gmane.org/gmane.comp.graphics.gnuplot.devel/1952/match=
=3Dadobe)=20
>> :
>>
>> "Please note that this terminal is outdated and, as PostScript is=20
>> understood by *Adobe* Illustrator, the `post` should be used instead."
>>    =20
>
> That should be "set term post level1 ...."
>  =20
Ok.

Best regards,

Timoth=C3=A9e

Re: Doc : "ai driver deprecated"

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

On Friday 28 July 2006 08:41 pm, Timoth=C3=A9e Lecomte wrote:
"Adobe Illustrator (ai) driver deprecated".
>=20
> What does it mean in practise ?
> Shouldn't this message rather be in "help ai" instead of the news section=
 ?

We don't normally have entries for non-existent terminals in the help secti=
on.
I think NEWS or "Changes since 4.0" are the right place for such a warning.

> I propose to write this, taken from Harald Harders on this list=20
> (http://article.gmane.org/gmane.comp.graphics.gnuplot.devel/1952/match=3D=
adobe)=20
> :
>=20
> "Please note that this terminal is outdated and, as PostScript is=20
> understood by *Adobe* Illustrator, the `post` should be used instead."

That should be "set term post level1 ...."

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