Re: wxt file-save oddity

[Allin C. <cot...@wf...>]

On Sat, 15 Nov 2014, Daniel J Sebald wrote:

> On 11/15/2014 02:36 PM, sfeam wrote:
>>  On Saturday, 15 November 2014 03:07:27 PM Allin Cottrell wrote:
>> 
>> >   On Sat, 15 Nov 2014, sfeam wrote:
>> 
>> > >  On Saturday, 15 November 2014 01:54:32 PM Allin Cottrell wrote:
>> > > > >  On 11/15/2014 11:55 AM, Allin Cottrell wrote:
>> > > > > >  On Sat, 15 Nov 2014, Daniel J Sebald wrote:
>> > > > > > >  On 11/15/2014 11:36 AM, Allin Cottrell wrote:
>> > > > > > > >  I just tried out the file save button in the gnuplot wxt 
>> > > > > > > >  window. It
>> > > > > > > >  works nicely... except that I'm seeing a delay of up to 40 
>> > > > > > > >  seconds
>> > > > > > > >  between clicking the button and the file-save dialog 
>> > > > > > > >  opening.
>> > > > > > > > 
>> > > > > > > >  This is on a lightly loaded system, with gnuplot 
>> > > > > > > >  launched via gnuplot -persist<plotfile>.
>> > > > > > > 
>> > > > > > >  What operating system?
>> 
>> > > > > >  Arch Linux. No other programs showing odd delays in response.
>> 
>> > > >  Aha. No such problem if I run gnuplot interactively, load 
>> > > >  the plot file and display the plot. Then the Save button 
>> > > >  works instantly. The loooong delay just happens when 
>> > > >  gnuplot is run with -persist.
>> 
>> > > 
>> > >  In that case it might be informative to establish where the
>> > >  program is hung/delayed.
>> > >  Fire up gnuplot -persist, determinine its <pid>, then hit
>> > >  the problematic button.
>> > >  While it is in the hung state, from another terminal run
>> 
>> > >  $ gdb -p <pid>
>> 
>> > > gdb>  where
>> 
>> > >  to establish where the code is hung.
>> 
>> >   OK, I'm attaching the output from this.
>> >   Allin Cottrell
>>
>>  I can reproduce this now, so at least I can investigate as I
>>  find time. No ideas at the moment, other than it may indicate an
>>  interlock failure in the gvfs/dbus library code. We could report
>>  that upstream to gtk, but I am afraid that we would then run
>>  into the problem that upstream development is focused on gtk3,
>>  while the problem is occurring in 2.8. I suppose we could
>>  disable the Export-to-File widget in persist mode, but that
>>  would be unfortunate.
>
> I don't see this delay on my system (Gnome, GTK 2.0).
>
> If it still works, just slow, I'd say simply display some message "File 
> dialog in persist mode may run slow", the first time the user attempts to 
> save a file.  But lets see if there is a bug there first.
>
> One thing that I notice is that in the WXT setting (the wrench) there is a 
> check box for persist mode.  If launching gnuplot with "-persist", that check 
> box is not checked when I think it should be.
>
> If launching gnuplot without "-persist", does using the setting to change the 
> "persist" checkbox also result in a slowdown when trying to save a file?

Here are my results (again, with today's CVS):

1) I do: gnuplot -persist <plotfile>

The dialog opened by the wxt wrench icon shows the "persist" box 
checked; it always takes a long time for the Save dialog to appear.

2) I do: gnuplot (interactive) ; then 'load' plotfile

a) If I click the wxt wrench icon, the dialog shows the "persist" 
box checked. If I click the Save icon while the calling gnuplot 
instance is still active, it always works instantly.

(b) If I type 'quit' in the calling gnuplot instance, then try the 
Save icon in the wxt window, sometimes the Save dialog still comes 
up instantly and sometimes it takes ages. I haven't yet determined 
if there's any reliable predictor for the variant behaviors.

Allin Cottrell