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

Need Makefile help Re: GNUPLOT_PS_DIR

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

On Tuesday 18 July 2006 01:48 am, Bastian Maerkisch wrote:
> before I forget about it (again ;): right now the environment
> variable GNUPLOT_PS_DIR is not yet documented in gnuplot.doc.

I have added this to post.trm, but I notice a problem.
I made the documentation conditional on GNUPLOT_PS_DIR being
defined at compile-time. Otherwise we'd be documenting a feature
that wasn't compiled in.  This works fine for generating gnuplot.gih.

However, to build the *.tex, *.html, *.pdf documentation we
pass the source through the C preprocessor again to build the
conversion programs doc2tex and so on.  The Makefile in the .../docs
directory does not know about conditional compilation flags, so the
    #ifdef GNUPLOT_PS_DIR
parts of the documentation are lost.

What is the proper fix?
Should Makefile.in contain lines like those in .../src/Makefile.am

  GNUPLOT_PS_DIR=$(pkgdatadir)/$(VERSION_MAJOR)/PostScript
  AM_CPPFLAGS =  -DGNUPLOT_PS_DIR=\"$(GNUPLOT_PS_DIR)\"

(except I suppose it would be CPPFLAGS because it isn't coming
from a Makefile.am - when does one need the extra step am->in ??)

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

Re: odds and ends

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

> I have never like the "closing quote optional" behavior.

I like it!

---
PM

Re: Copy to clipboard for Linux

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

Daniel J Sebald wrote:

>>I am NOT going to look at this before 4.2
>>It would be insane to start fiddling with a major interface like
>>X11 just before a release.
> 
> 
> I'm thinking along the lines that 4.2 is pretty much set accept for any bugs someone asks me to fix.  (Just about got a bug fix ready here.)

If there is anything here that should be looked at before 4.2, maybe it is that one line change of moving XFLush() to before sending an event.  Perhaps we should investigate that.

Dan

Re: Copy to clipboard for Linux

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

Ethan Merritt wrote:
> On Tuesday 18 July 2006 01:44 pm, Daniel J Sebald wrote:
> 
>>Well, give the patch I made a try.  
> 
> 
> I am NOT going to look at this before 4.2
> It would be insane to start fiddling with a major interface like
> X11 just before a release.

I'm thinking along the lines that 4.2 is pretty much set accept for any bugs someone asks me to fix.  (Just about got a bug fix ready here.)

As for someone who could look at this, I mean the people with interest and who asked about the clipboard initially.


>>As far as I see it, there is now 
>>a way to put things in the PRIMARY and CLIPBOARD.  If there is a
>>version of X that doesn't use one of those mechanisms (which are
>>called out in the X documentation) then that is its problem.
> 
> 
> Please read the previous thread.  The issue is not what X11 wants.
> The issue is that major user environments like KDE, and major apps
> like OpenOffice, ignore this and do something else.

Do you mean OpenOffice in KDE?  Because the patch provides both PRIMARY and CLIPBOARD for OpenOffice in Gnome and it works as expected.


> And then they
> change it from version to version.
> 
> Any argument from the standard or the X11 docs is pointless.
> This has to work on real machines for real users.

I don't think it is pointless.  If KDE or some other environment reacts to just PRIMARY or just CLIPBOARD, then they still have a form of getting the Pixmap.

Dan

Re: odds and ends

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

Ethan Merritt wrote:

>>load 'foo' dem
> 
> 
> I argue that it should be considered a syntax error, and
> not interpreted at all.
> 
> I have never like the "closing quote optional" behavior.

Well, I agree with you there.  I've gotten in this bad habit of leaving off that final quotation.  (And to be honest, not realizing I had a space after the name because there was no closing quote is what lead to my inquiry.)

Dan

Re: Copy to clipboard for Linux

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

Timoth=E9e Lecomte wrote:

>>Correct.  I think the important thing we are try to address is the=20
>>race condition Ethan describes.  One in which the Pixmap doesn't seem=20
>>to successfully make it over to the application (client) requesting=20
>>it.  We were handling the request, but sometimes the trasfer was=20
>>unsuccessful.
>=20
> Ok, I'm a little late in this thread, but in what conditions did the=20
> transfer failed ? How can I reproduce it ?

Without adding some code to verify gnuplot_x11.c is getting requests but =
the plot is not appearing, I guess just try selecting (i.e., clipboarding=
) a plot Pixmap and attempting to paste in OpenWrite.  Check if there is =
a feeling of inconsistency, i.e., that the Pixmap doesn't appear to trans=
fer even though you believe you've pressed the button.

>=20
>>>I must admit that I am a little lost in this thread. Can you repeat=20
>>>what you're trying to solve/achieve ?
>>>
>>>I think that Dave was probably talking about this=20
>>>(gplot_x11.c:5924:export_graph):
>>>
>>>   XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime=
);
>>
>>Well, that is an issue Dave raised.  But I think he basically answered=20
>>that question himself by stating that time stamp is used to resolve=20
>>conflicts in who gets control of the selection.  For example, if two X=20
>>windows request control at very near the same time and both of them=20
>>request CurrentTime, I'm guessing that X has no recourse but to make a=20
>>random choice.
>=20
> Agreed, so it may not be the origin of the unsuccessful transfer, but=20
> it's worth trying.

Sure, but I think moving that XFlush() command to before sending an event=
 to the requesting client puts us in the realm of reasonable understandin=
g (Dave hasn't disagreed with that yet, I think) and at the same time app=
ears to fix the problem.  Perhaps someone else could test and verify the =
code.

>=20
>>>where we indeed use CurrentTime which is definitely not the time when=20
>>>the event was triggered. Could be interesting to change CurrentTime=20
>>>to plot->time, or rather :
>>>
>>>   (!plot || !(plot->time)) ? CurrentTime : plot->time
>>
>>Ehhhh.  Not sure.  Don't think that will achieve anything.  The plot=20
>>could have been created an hour ago and we'd be saying we want to take=20
>>control of the PRIMARY selection or CLIPBOARD at a time one hour ago. =20
>>(I think X would realize that something is not right about that and=20
>>deal with it.)  Unless we want to be very accurate about when the=20
>>button or key is pressed that activates Selection, CurrentTime is=20
>>probably best choice.
>=20
> Well, you acquire the selection once, when it's ready, not one hour=20
> later.

But that is the issue I'm making.  I keep wondering why we should program=
 gnuplot to behave significantly different from usual X behavior.  Is it =
nice to have gnuplot automatically saving to the clipboard without being =
initiated to do so?  Obviously not; that is the reason for adding the abi=
lity to turn off "export plot".  Otherwise users will not like that their=
 clipboard is being overwritten.

I guess I was thinking along the lines of the mouse click or key press or=
 "set output clipboard; plot x" activating the Selection, where the plot =
time and selection time could be different.  I see what you were thinking=
 though.

> That's why this XSetSelectionOwner() call is made in record() and=20
> display() but that's all. You don't call it later, that's useless.

As it is program, useless yes.  But not in the conventional X method.

> However, when it's called, it should be provided the right timestamp.=20
> CurrentTime probably means "use the current time when the server=20
> processes the XSetSelectionOwner call", which is a little later.

It's clear I've rearranged the concept, but I think I'm trying to move mo=
re along the lines of X expected behavior.

Dan

Re: odds and ends

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

Ethan Merritt wrote:
> On Tuesday 18 July 2006 01:10 pm, Hans-Bernhard Br=F6ker wrote:

>> As of the CVS version right now, trailing blanks apparently get
>> ignored at least in the Windows version.  That's a bug.

> Not under linux:
>=20
> gnuplot> set term png
> gnuplot> set output 'foo.png  '

Erm, I was talking about the 'load' command, not 'set output'.  But s=
ame=20
difference:

=09set output 'foo.pbm '

writes a file that's actually called 'foo.pbm'.  This *might* be a=
=20
feature of the file system or the compiler's runtime lib, though.  Th=
is=20
is Windows after all...

Re: Copy to clipboard for Linux

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

On Tuesday 18 July 2006 01:44 pm, Daniel J Sebald wrote:
> Well, give the patch I made a try.  

I am NOT going to look at this before 4.2
It would be insane to start fiddling with a major interface like
X11 just before a release.

> As far as I see it, there is now 
> a way to put things in the PRIMARY and CLIPBOARD.  If there is a
> version of X that doesn't use one of those mechanisms (which are
> called out in the X documentation) then that is its problem.

Please read the previous thread.  The issue is not what X11 wants.
The issue is that major user environments like KDE, and major apps
like OpenOffice, ignore this and do something else.  And then they
change it from version to version.

Any argument from the standard or the X11 docs is pointless.
This has to work on real machines for real users.

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

Re: odds and ends

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

On Tuesday 18 July 2006 01:35 pm, Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
> > Daniel J Sebald wrote:
> >>>No, leading and trailing whitespace inside strings should *not* be
> >>>ignored. If the code currently does that, that's a bug.
> >>
> >>You mean "currently doesn't do that", I think.  (I originally
> >> framed the issue as double negative, but so no other way.)
> >
> > No.  I meant exactly what I wrote.  If blanks *anywhere* inside the
> > delimeters of a string passed to gnuplot get ignored, that's a bug,
> > period.
>
> Right.  That is currently how linux works.
> If blanks are to matter, I contend that invisible blanks should not
> be strip even in the case of
>
> load 'foo.dem
>
> Because then one could argue that the following
>
> load 'foo  dem
>
> should be interpretted as
>
> load 'foo' dem

I argue that it should be considered a syntax error, and
not interpreted at all.

I have never like the "closing quote optional" behavior.


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

Re: Copy to clipboard for Linux

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

Ethan Merritt wrote:
> On Tuesday 18 July 2006 03:06 pm, Timoth=E9e Lecomte wrote:
>=20
>>>Correct.  I think the important thing we are try to address is the
>>>race condition Ethan describes.  One in which the Pixmap doesn't
>>>seem to successfully make it over to the application (client)
>>>requesting it.  We were handling the request, but sometimes the
>>>trasfer was unsuccessful.
>=20
>=20
> Who, me?
> I didn't say anything about a race condition.

You're right.  Sorry.  Your comment was:

"If you allow the selection to remain active
(multiple pastes) then some window managers spin endlessly,
using 100% of CPU."


> What is the problem you are trying to solve?
> So far as I know the clipboard stuff is currently working as well,
> or better, than it did before.

I'm not sure it does.  Someone indicated that the pasting of the image in=
 OpenWriter took two or three presses of the mouse...   I printed out the=
 Atoms that gnuplot_x11.c was receiving, and yes it was receiving the ato=
ms and responding but some times the plot would not appear.

>=20
> My only contribution to this thread was to point out that we
> discovered during the last go-round that different versions of KDE
> (in particular different versions of klipper) and different versions
> of OpenOffice all play fast-and-loose with the supposedly "standard"
> protocol for the X clipboard.  Following the standard doesn't help
> if the apps you are trying to work with do not themselves follow it.
>=20
> All of these issues with timestamps and selection requests were
> involved, and it seemed at the time that only an empirical fix
> was possible.  Certainly no "fix" can be accepted if it doesn't
> work with the whole range of window managers that are likely to
> be used.

Well, give the patch I made a try.  As far as I see it, there is now a wa=
y to put things in the PRIMARY and CLIPBOARD.  If there is a version of X=
 that doesn't use one of those mechanisms (which are called out in the X =
documentation) then that is its problem.

It may be that in KDE one must use one or the other.  But again, we can a=
lways provide a term option to configure the behavior.  Why aim for the l=
owest common denominator?

Dan

Re: odds and ends

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>=20
>>>No, leading and trailing whitespace inside strings should *not* be=20
>>>ignored. If the code currently does that, that's a bug.
>=20
>=20
>>You mean "currently doesn't do that", I think.  (I originally framed
>>the issue as double negative, but so no other way.)
>=20
>=20
> No.  I meant exactly what I wrote.  If blanks *anywhere* inside the=20
> delimeters of a string passed to gnuplot get ignored, that's a bug,=20
> period.

Right.  That is currently how linux works.

>=20
> As of the CVS version right now, trailing blanks apparently get ignored=
=20
> at least in the Windows version.  That's a bug.  IIRC from the earlier=20
> discussion, this was found to be an unintentional side effect of the=20
> intended tolerance towards forgetting the closing quote.  I.e. while it=
=20
> makes some sense to interpret
>=20
> 	load 'foo.dem
>=20
> (note: two trailing blanks after 'dem', but not closing quote) as
>=20
> 	load 'foo.dem'
>=20
> and strip those invisible blanks, the same is *not* the case for
>=20
> 	load 'foo.dem '

If blanks are to matter, I contend that invisible blanks should not be st=
rip even in the case of

load 'foo.dem =20

Because then one could argue that the following

load 'foo  dem

should be interpretted as

load 'foo' dem

>=20
> "foo.dem " is a legal (though highly unusual) file name on at least som=
e=20
> platforms, and it indicates a different file than "foo.dem".  It's thus=
=20
> a clear bug if gnuplot can't access that file even though its exact nam=
e=20
> has been passed by the user.

There may be a bug in the Windows version.  I don't have Windows access.

Dan

Re: odds and ends

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

On Tuesday 18 July 2006 01:10 pm, Hans-Bernhard Br=F6ker wrote:
>
> As of the CVS version right now, trailing blanks apparently get
> ignored at least in the Windows version.  That's a bug.

Not under linux:

gnuplot> set term png
gnuplot> set output 'foo.png  '
gnuplot> test
gnuplot> quit

# file foo.png
foo.png: cannot open `test.png' (No such file or directory)
# file 'foo.png  '
foo.png  : PNG image data, 640 x 480, 8-bit colormap, non-interlaced

I'll have to leave windows-specific bugs to someone else.

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

Re: PlotWS software

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

> http://www.omii.ac.uk/docs/2.3.3/managed_programme/plotws/about_plotws.htm

Well, I asked for *other* web software ... but maybe someone provides it;
currently PlotWS is the only one in its category on the "Links" gnuplot web 
page section.

---
PM

Re: Copy to clipboard for Linux

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

On Tuesday 18 July 2006 03:06 pm, Timoth=E9e Lecomte wrote:
> >
> > Correct.  I think the important thing we are try to address is the
> > race condition Ethan describes.  One in which the Pixmap doesn't
> > seem to successfully make it over to the application (client)
> > requesting it.  We were handling the request, but sometimes the
> > trasfer was unsuccessful.

Who, me?
I didn't say anything about a race condition.

What is the problem you are trying to solve?
So far as I know the clipboard stuff is currently working as well,
or better, than it did before.

My only contribution to this thread was to point out that we
discovered during the last go-round that different versions of KDE
(in particular different versions of klipper) and different versions
of OpenOffice all play fast-and-loose with the supposedly "standard"
protocol for the X clipboard.  Following the standard doesn't help
if the apps you are trying to work with do not themselves follow it.

All of these issues with timestamps and selection requests were
involved, and it seemed at the time that only an empirical fix
was possible.  Certainly no "fix" can be accepted if it doesn't
work with the whole range of window managers that are likely to
be used.

Please see previous thread for details.




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

Re: odds and ends

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

Daniel J Sebald wrote:

>> No, leading and trailing whitespace inside strings should *not* be 
>> ignored. If the code currently does that, that's a bug.

> You mean "currently doesn't do that", I think.  (I originally framed
> the issue as double negative, but so no other way.)

No.  I meant exactly what I wrote.  If blanks *anywhere* inside the 
delimeters of a string passed to gnuplot get ignored, that's a bug, 
period.

As of the CVS version right now, trailing blanks apparently get ignored 
at least in the Windows version.  That's a bug.  IIRC from the earlier 
discussion, this was found to be an unintentional side effect of the 
intended tolerance towards forgetting the closing quote.  I.e. while it 
makes some sense to interpret

	load 'foo.dem

(note: two trailing blanks after 'dem', but not closing quote) as

	load 'foo.dem'

and strip those invisible blanks, the same is *not* the case for

	load 'foo.dem '

"foo.dem " is a legal (though highly unusual) file name on at least some 
platforms, and it indicates a different file than "foo.dem".  It's thus 
a clear bug if gnuplot can't access that file even though its exact name 
has been passed by the user.

> (Whoever came up with the idea of white space in computer file names?
> Ever list a directory with such files?  It's downright confusing.)

Of course it's confusing.  But that's the way it is.  Water under the 
bridge.

Re: Copy to clipboard for Linux

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

Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
>> Daniel J Sebald wrote:
>>
>>> Timoth=E9e Lecomte wrote:
>>> =20
>>>
>>>> Dave Denholm wrote:
>>>>
>>>>  =20
>>>>> Ah - tell you what - there is one thing that is timing dependent.
>>>>>
>>>>> When you acquire a selection, you're supposed to give a
>>>>> timestamp. That is a server time, and it usually comes from the X
>>>>> event that triggered the action to acquire the selection. But gnupl=
ot
>>>>> doesn't have such an event. IIRC, we use "currenttime" for that, bu=
t
>>>>> that isn't a real time.
>>>>>        =20
>>>>
>>>> Hmm. I wrote the code just a few months ago to provide this=20
>>>> timestamp. I took the time as plot->time. I realise now that this=20
>>>> time is only updated at a button release event, and put to 0 at=20
>>>> each "record", so if the user doesn't click on the window this=20
>>>> timestamp may have a useless value.
>>>>    =20
>>>
>>>
>>> Could have been a problem.  But I eventually whittled things down to=20
>>> the one problem Dave is keen to.  I did notice that the client used=20
>>> to call a XA_TIMESTAMP selector request.  But now it no longer=20
>>> does.  Perhaps that was an issue (that X could resolve with the=20
>>> XA_TIMESTAMP property request), and now has gone away.
>>>  =20
>>
>> Well, X itself does not call XA_TIMESTAMP, but other applications=20
>> that check for the content of the clipboard/selection like klipper.=20
>> Without XA_TIMESTAMP, klipper would infinitely retrieve the pixmap=20
>> provided by gnuplot, even if it did not change.
>>
>> But that's not the race condition you're talking about, right ?
>
> Correct.  I think the important thing we are try to address is the=20
> race condition Ethan describes.  One in which the Pixmap doesn't seem=20
> to successfully make it over to the application (client) requesting=20
> it.  We were handling the request, but sometimes the trasfer was=20
> unsuccessful.
Ok, I'm a little late in this thread, but in what conditions did the=20
transfer failed ? How can I reproduce it ?
>
>> I must admit that I am a little lost in this thread. Can you repeat=20
>> what you're trying to solve/achieve ?
>>
>> I think that Dave was probably talking about this=20
>> (gplot_x11.c:5924:export_graph):
>>
>>    XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime=
);
>
> Well, that is an issue Dave raised.  But I think he basically answered=20
> that question himself by stating that time stamp is used to resolve=20
> conflicts in who gets control of the selection.  For example, if two X=20
> windows request control at very near the same time and both of them=20
> request CurrentTime, I'm guessing that X has no recourse but to make a=20
> random choice.
Agreed, so it may not be the origin of the unsuccessful transfer, but=20
it's worth trying.
>
>>
>> where we indeed use CurrentTime which is definitely not the time when=20
>> the event was triggered. Could be interesting to change CurrentTime=20
>> to plot->time, or rather :
>>
>>    (!plot || !(plot->time)) ? CurrentTime : plot->time
>
> Ehhhh.  Not sure.  Don't think that will achieve anything.  The plot=20
> could have been created an hour ago and we'd be saying we want to take=20
> control of the PRIMARY selection or CLIPBOARD at a time one hour ago. =20
> (I think X would realize that something is not right about that and=20
> deal with it.)  Unless we want to be very accurate about when the=20
> button or key is pressed that activates Selection, CurrentTime is=20
> probably best choice.
Well, you acquire the selection once, when it's ready, not one hour=20
later. That's why this XSetSelectionOwner() call is made in record() and=20
display() but that's all. You don't call it later, that's useless.
However, when it's called, it should be provided the right timestamp.=20
CurrentTime probably means "use the current time when the server=20
processes the XSetSelectionOwner call", which is a little later.
>
> But, at the same time, there is the related issue that if the other=20
> client asks for a XA_TIMESTAMP we should be able to provide, again,=20
> definetly not the time of the plot, but we shouldn't then say=20
> CurrentTime.  We should be saying the time the button was pressed. =20
> Keep a record of that somehow.  (I can fix this up later.)
>
> But still, since OpenWrite didn't seem to be asking me for=20
> XA_TIMESTAMP, I don't think the reason for unsuccessful transfer was=20
> the time stamp issue.  It is the XFlush().
XA_TIMESTAMP and the unsuccessful transfer are two unrelated issues. I=20
am sorry I talked about that, it seems it made you confused.

Best regards,

Timoth=E9e

Re: Copy to clipboard for Linux

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

Timoth=E9e Lecomte wrote:
> Daniel J Sebald wrote:
>=20
>> Timoth=E9e Lecomte wrote:
>> =20
>>
>>> Dave Denholm wrote:
>>>
>>>   =20
>>>
>>>> Ah - tell you what - there is one thing that is timing dependent.
>>>>
>>>> When you acquire a selection, you're supposed to give a
>>>> timestamp. That is a server time, and it usually comes from the X
>>>> event that triggered the action to acquire the selection. But gnuplo=
t
>>>> doesn't have such an event. IIRC, we use "currenttime" for that, but
>>>> that isn't a real time.
>>>>        =20
>>>
>>> Hmm. I wrote the code just a few months ago to provide this=20
>>> timestamp. I took the time as plot->time. I realise now that this=20
>>> time is only updated at a button release event, and put to 0 at each=20
>>> "record", so if the user doesn't click on the window this timestamp=20
>>> may have a useless value.
>>>    =20
>>
>>
>> Could have been a problem.  But I eventually whittled things down to=20
>> the one problem Dave is keen to.  I did notice that the client used to=
=20
>> call a XA_TIMESTAMP selector request.  But now it no longer does. =20
>> Perhaps that was an issue (that X could resolve with the XA_TIMESTAMP=20
>> property request), and now has gone away.
>>  =20
>=20
> Well, X itself does not call XA_TIMESTAMP, but other applications that=20
> check for the content of the clipboard/selection like klipper. Without=20
> XA_TIMESTAMP, klipper would infinitely retrieve the pixmap provided by=20
> gnuplot, even if it did not change.
>=20
> But that's not the race condition you're talking about, right ?

Correct.  I think the important thing we are try to address is the race c=
ondition Ethan describes.  One in which the Pixmap doesn't seem to succes=
sfully make it over to the application (client) requesting it.  We were h=
andling the request, but sometimes the trasfer was unsuccessful.

> I must=20
> admit that I am a little lost in this thread. Can you repeat what you'r=
e=20
> trying to solve/achieve ?
>=20
> I think that Dave was probably talking about this=20
> (gplot_x11.c:5924:export_graph):
>=20
>    XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime)=
;

Well, that is an issue Dave raised.  But I think he basically answered th=
at question himself by stating that time stamp is used to resolve conflic=
ts in who gets control of the selection.  For example, if two X windows r=
equest control at very near the same time and both of them request Curren=
tTime, I'm guessing that X has no recourse but to make a random choice.

>=20
> where we indeed use CurrentTime which is definitely not the time when=20
> the event was triggered. Could be interesting to change CurrentTime to=20
> plot->time, or rather :
>=20
>    (!plot || !(plot->time)) ? CurrentTime : plot->time

Ehhhh.  Not sure.  Don't think that will achieve anything.  The plot coul=
d have been created an hour ago and we'd be saying we want to take contro=
l of the PRIMARY selection or CLIPBOARD at a time one hour ago.  (I think=
 X would realize that something is not right about that and deal with it.=
)  Unless we want to be very accurate about when the button or key is pre=
ssed that activates Selection, CurrentTime is probably best choice.

But, at the same time, there is the related issue that if the other clien=
t asks for a XA_TIMESTAMP we should be able to provide, again, definetly =
not the time of the plot, but we shouldn't then say CurrentTime.  We shou=
ld be saying the time the button was pressed.  Keep a record of that some=
how.  (I can fix this up later.)

But still, since OpenWrite didn't seem to be asking me for XA_TIMESTAMP, =
I don't think the reason for unsuccessful transfer was the time stamp iss=
ue.  It is the XFlush().

Dan

"help set term foo" not working

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

Dan:

Can I tear your attention away from post-4.2 projects like
re-writing X11, and ask you to instead have a look at the
help system?  You submitted a patch to strip things down
and rely on run-time expansion of shorthand keywords, but
it seems to be broken.

gnuplot> help set term post
Sorry, no help for 'set term post'
gnuplot> help set terminal post
 Several options may be set in the `postscript` driver.

 Syntax:
 [...... many lines .....]

In the interest of getting 4.2 out the door, should I just
revert the earlier patches that broke this?

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

Re: Copy to clipboard for Linux

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

Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
>  =20
>> Dave Denholm wrote:
>>
>>    =20
>>> Ah - tell you what - there is one thing that is timing dependent.
>>>
>>> When you acquire a selection, you're supposed to give a
>>> timestamp. That is a server time, and it usually comes from the X
>>> event that triggered the action to acquire the selection. But gnuplot
>>> doesn't have such an event. IIRC, we use "currenttime" for that, but
>>> that isn't a real time.
>>>  =20
>>>      =20
>> Hmm. I wrote the code just a few months ago to provide this timestamp.=
 I=20
>> took the time as plot->time. I realise now that this time is only=20
>> updated at a button release event, and put to 0 at each "record", so i=
f=20
>> the user doesn't click on the window this timestamp may have a useless=
=20
>> value.
>>    =20
>
> Could have been a problem.  But I eventually whittled things down to th=
e one problem Dave is keen to.  I did notice that the client used to call=
 a XA_TIMESTAMP selector request.  But now it no longer does.  Perhaps th=
at was an issue (that X could resolve with the XA_TIMESTAMP property requ=
est), and now has gone away.
>  =20
Well, X itself does not call XA_TIMESTAMP, but other applications that=20
check for the content of the clipboard/selection like klipper. Without=20
XA_TIMESTAMP, klipper would infinitely retrieve the pixmap provided by=20
gnuplot, even if it did not change.

But that's not the race condition you're talking about, right ? I must=20
admit that I am a little lost in this thread. Can you repeat what you're=20
trying to solve/achieve ?

I think that Dave was probably talking about this=20
(gplot_x11.c:5924:export_graph):

    XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime);

where we indeed use CurrentTime which is definitely not the time when=20
the event was triggered. Could be interesting to change CurrentTime to=20
plot->time, or rather :

    (!plot || !(plot->time)) ? CurrentTime : plot->time


Best regards,

Timoth=E9e

Re: odds and ends

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> I've probably asked this before, but preceding and trailing white
>> spaces... should those not be ignored as the code currently does?
>=20
>=20
>> gnuplot> load ' histograms.dem'
>>                                ^
>>          Cannot open load file ' histograms.dem'
>>          util.c: No such file or directory
>=20
>=20
>> gnuplot> load 'histograms.dem '
>>                                ^
>>          Cannot open load file 'histograms.dem '
>>          util.c: No such file or directory
>=20
>=20
> Erm... are you sure this question makes sense as written?
>=20
> No, leading and trailing whitespace inside strings should *not* be
> ignored. If the code currently does that, that's a bug.

You mean "currently doesn't do that", I think.  (I originally framed the =
issue as double negative, but so no other way.)

As far as strings are concerned, trailing white space should not be ignor=
ed.  But when it comes to the point of attempting to open a file, can the=
 trailing whitespace be ignored?...  Oo, I guess I should retract that.  =
I just attempted to open something in gvim and placed white space before =
and after the name.  gvim created a new file with spaces instead of openi=
ng the file I intended.

(Whoever came up with the idea of white space in computer file names?  Ev=
er list a directory with such files?  It's downright confusing.)


>> For the history readline, the Home key places an "OH" in the line and
>> the End key places an "OF" in the command line. =20
>=20
>=20
> There's an off chance you can fix that by turning of "application curso=
r=20
> keys" mode in your xterm.

I wondered about that.  I see some keyboard settings in my xterm, but not=
hing having to do with the end and home keys.  I'll investigate.

Dan

Re: odds and ends

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

Daniel J Sebald wrote:

> I've probably asked this before, but preceding and trailing white
> spaces... should those not be ignored as the code currently does?

> gnuplot> load ' histograms.dem'
>                                ^
>          Cannot open load file ' histograms.dem'
>          util.c: No such file or directory

> gnuplot> load 'histograms.dem '
>                                ^
>          Cannot open load file 'histograms.dem '
>          util.c: No such file or directory

Erm... are you sure this question makes sense as written?

No, leading and trailing whitespace inside strings should *not* be
ignored. If the code currently does that, that's a bug.

> For the history readline, the Home key places an "OH" in the line and
> the End key places an "OF" in the command line.  

There's an off chance you can fix that by turning of "application cursor 
keys" mode in your xterm.

Re: PlotWS software

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

Kim Leng Goh wrote:

> I was following the instructions from http://www.gnuplot.info/links.html :
> "This is a completely unorganised list of gnuplot related web and ftp
> sites. Please write to gnuplot-beta mailing list if you know any other
> useful links."

For telling us about the program, you followed it correctly.  But that 
doesn't mean we're interested in reading about possible bugs in other
people's programs.  Even if those programs use gnuplot.

>> > 1) Modify GraphSoapBindingImpl.java and change
>> > exe.run(exeGnuPlot + " \"" + cmdsFile + "\"", _tempDir, null);
>> > to
>> > exe.run(exeGnuPlot + " " + cmdsFile, _tempDir, null);
>>
>> I don't think that's a good change.  After your change, any use of a
>> plot filename containing blanks would fail.  This change breaks more
>> than it fixes
> 
> Without the change, it doesn't work for me. Maybe it works on Windows.
> 
> btw, the plot filename won't contain blanks (ah hah, thanks, now I
> what those quotes and back slashes were for):

How can you possibly be sure about that?  For all you know, a user could 
well have set up his system such that

> GraphSoapBindingImpl.java:  cmdsFile = File.createTempFile("gnuplot_",
> ".cmds", _tempDir);

returns a pathname with a blank somewhere inside it.  Note it doesn't 
have to be in the filename part of the pathname --- it could be in 
_tempDir, though.

Re: Copy to clipboard for Linux

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

Timoth=E9e Lecomte wrote:
> Dave Denholm wrote:
>=20
>> Ah - tell you what - there is one thing that is timing dependent.
>>
>> When you acquire a selection, you're supposed to give a
>> timestamp. That is a server time, and it usually comes from the X
>> event that triggered the action to acquire the selection. But gnuplot
>> doesn't have such an event. IIRC, we use "currenttime" for that, but
>> that isn't a real time.
>>  =20
>=20
> Hmm. I wrote the code just a few months ago to provide this timestamp. =
I=20
> took the time as plot->time. I realise now that this time is only=20
> updated at a button release event, and put to 0 at each "record", so if=
=20
> the user doesn't click on the window this timestamp may have a useless=20
> value.

Could have been a problem.  But I eventually whittled things down to the =
one problem Dave is keen to.  I did notice that the client used to call a=
 XA_TIMESTAMP selector request.  But now it no longer does.  Perhaps that=
 was an issue (that X could resolve with the XA_TIMESTAMP property reques=
t), and now has gone away.

Dan

Re: Copy to clipboard for Linux

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

Dave Denholm wrote:

> There is a predefined atom for the string "PIXMAP", which is used to
> identify the type of the property.
> 
> $ xlsatoms | grep PIXMAP
> 20      PIXMAP
> 
> Atom is a well-defined term in X, so any documentation that misuses
> the term is broken.

Yes, I'm not fluent in the terminology, but I understand.


>>>I'm sceptical about that. And all that arrives on the other client is
>>>an event that the property has changed. The client still has another
>>>round-trip to get hold of the value you've written. So the X server
>>>has a lot of time to finish its work, even if it was doing things out
>>>of order.
>>
>>Unless perhaps it is a fairly huge Pixmap in X's world where sparsity rules.
>>
> 
> 
> Don't think so. If the X server does decide to defer some work, it
> will have to somehow lock the pixmap, and then when someone tries to access it,
> block that client until the work is done.

There is discussion in the documentation about large data transfers.  Can't say I totally understand it, but that is where we seemed to consistently have the problem.

> 
> 
>>>A simpler way to change the timing would be to do an XFlush between
>>>the ChangeProperty and the SendEvent.
>>
>>And I believe that is right.  (It finally dawned on me.)
>>
> 
> 
> I agree it's a simpler way to change the timing. But if you are
> relying on timing, the code is broken somewhere.
> 
> Ah - tell you what - there is one thing that is timing dependent.
> 
> When you acquire a selection, you're supposed to give a
> timestamp. That is a server time, and it usually comes from the X
> event that triggered the action to acquire the selection. But gnuplot
> doesn't have such an event. IIRC, we use "currenttime" for that, but
> that isn't a real time.
> 
> The X server uses the timestamp to resolve if two separate clients try
> to acquire the same selection : the later time should win. Maybe the
> problem is in that part of the code.

That did concern me, because we don't handle that gracefully.  But I can't imagine how that could cause a problem.

Hold on, let me say there is more that I added, and maybe it is more crucial to the problem than I would think.  Now, I changed things slightly in the sense that I want the client to have a copy of the pixmap that doesn't have the mouse coordinates along the bottom of the Pixmap.  To do that, in the midst of this handling of the selection request I've added:

/* Want only the graph portion of Pixmap */
if (requested_pixmap == &selected_pixmap && *requested_pixmap != None) {
[snip]
    if (storage_pixmap != None)
	XFreePixmap(dpy, storage_pixmap);
[snip]
	storage_pixmap = XCreatePixmap(dpy, root, plot->width, GRAPH_HEIGHT(plot), dep);
	if (storage_pixmap != None) {
	    /* Composited for highlight, undo that before copying. */
	    CompositeWindow(plot, 0);
	    XCopyArea(dpy, plot->pixmap, storage_pixmap, *current_gc, 0, 0, plot->width, GRAPH_HEIGHT(plot), 0, 0);
	    CompositeWindow(plot, 1);
	}
[snip]

(The CompositeWindow() stuff is to turn off and back on the inverse video effect.  I seemed to have little issue with those... as you say, those seemed to happen contiguously with no problems.)

The above lines of code did seem to add to the bad behavior.

I'm almost certain I read somewhere that things don't happen in X necessarily when you think they will.  So even though things happen contiguously, could it be they happen later than one might think?  That is, without the XFlush, all the above stuff I added, which admittedly is a lot of processing from X's perspective is deferred and not finished before the client window, the requestor, gets its event to proceed?

And here is a bit more information.  The XCopyArea(), here and in other locations, appears to return with a non-Success value, it returns BadRequest, a value of 1.  I always thought Odd, that seems to work fine.  However, maybe that non-Success indication simply means X can't do all that right now so it is deferring the operation until a little later in its refresh cycle (or whatever terminology).

So maybe we should be checking for that BadRequest value and if we find it, *then* we need to XFlush().  (Or, we just always XFlush.)  Again, things are contiguous for our window, so that BadRequest is no problem for gnuplot_x11, but it is for any outside client.

Dan

Re: Copy to clipboard for Linux

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

Dave Denholm wrote:
> Ah - tell you what - there is one thing that is timing dependent.
>
> When you acquire a selection, you're supposed to give a
> timestamp. That is a server time, and it usually comes from the X
> event that triggered the action to acquire the selection. But gnuplot
> doesn't have such an event. IIRC, we use "currenttime" for that, but
> that isn't a real time.
>  =20
Hmm. I wrote the code just a few months ago to provide this timestamp. I=20
took the time as plot->time. I realise now that this time is only=20
updated at a button release event, and put to 0 at each "record", so if=20
the user doesn't click on the window this timestamp may have a useless=20
value.
> The X server uses the timestamp to resolve if two separate clients try
> to acquire the same selection : the later time should win. Maybe the
> problem is in that part of the code.
>
>
> dd
>  =20

Best regards,

Timoth=E9e