[rkward-devel] updateHistoryActions and rInterface ()->issueCommand

[Prasenjit Kapat]

Hi

On Sun, Jul 4, 2010 at 7:04 AM, Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
> Hi,
>
> On Sunday 04 July 2010, Prasenjit Kapat wrote:
>> A question regarding the following function  (or nextPlot() or
>> firstPlot() or ...) in rkwindowcatcher.cpp.
>
> I'll in a somewhat different order:
> - I think the only safe assumption regarding the state of the history is that
> the R code knows the "true" state of the history at all times, while the code
> in RKWard does not. This will become even more relevant once you implement
> history length/size limits. But also, sine rk.next.plot() and friends are
> publicly visible, we should assume people might use them from R, directly,
> even though it will be used via the tool-buttons *most* of the time.
> - The calls to updateHistoryActions() in the C++ code really are not very
> important for that reason. In adding them, I was thinking about the corner
> case where R is still busy (or replaying the plot takes a considerable amount
> of time). Here the idea was to give a graphical indication immediately, while
> .rk.graph.history.gui() will not be called immediately. And it was easy to
> do... Of course if this is not always correct, as you write, then maybe it is
> not worth doing.
> (Side note: The C++-code also only takes care of updating the actions in the
> current device, while - if history length changes - all devices will need to
> be updated).
>
>> Does it matter if updateHistoryActions (...) is called before or after
>> calling RKGlobals::rInterface ()->issueCommand (...)?
>
> Technically, no. Commands run asynchronously, and while you can never tell
> whether the command will get run immediately or later, RKWard will not see
> anything about that command (including the callback from
> .rk.graph.history.gui()) until the next iteration of the event loop. Thus,
> putting updateHistoryActions() after issueCommand() would not make a
> difference. But since updateHistoryActions() *will* happen first, it makes sense
> to place it first for readability. I see that I did not do so, consistently.
>
>> If the R command (in the variable 'c') changes the length of the
>> history then, is the updateHistoryAction (....) call aware (or
>> unaware) of this change? I think it is not!
>
> It is not, or at least only in some cases (for instance when clearing the
> history, we know that the new length (and position) will be 0, so in
> clearHistory() we have updateHistoryActions (0, 0).
>
[snip]

Thanks for the detailed explanation. My reply is going to be very terse ;)

The conclusion is that, asynchronous calls and the possibility that a
user may call rk.next.plot () and friends directly, makes it
unnecessary to call updateDeviceHistory (...) in the C++ functions
(nextPlot () and friends).

So, lets keep them commented in C++ for now and see how it goes. I'll
revisit this later. (Note for self: see PS below.)

Regards,
-- 
Prasenjit

PS: I think it is safe to call updateDeviceHistory () in the C++
functions except for these two functions: recordCurrentPlot () and
removeCurrentPlot ().