Hi On Sun, Jul 4, 2010 at 7:04 AM, Thomas Friedrichsmeier <thomas.friedrichsme...@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 (). ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
