Hi,
On Sun, Sep 5, 2010 at 7:23 AM, Thomas Friedrichsmeier
<thomas.friedrichsme...@ruhr-uni-bochum.de> wrote:
> Hi,
>
> On Saturday 04 September 2010, Prasenjit Kapat wrote:
>> Indeed. I'll need to go back to drawing board and try to implement
>> things differently. Before getting into specific cases, I am
>> suggesting, in the interest of the upcoming release, that let us
>> ignore this plot history feature completely. Why? There is another
>> core problem:
>>
>> par (mfrow = c(2,2))
>> plot (1,1); plot (2,1); plot (1,2); plot (2,2)
>>
>> A similar problem occurs for screen calls. For example, follow one of
>> the examples in ?screen. I am not sure, how / if we can avoid this! Is
>> this an "acceptable" drawback for a released software? I would guess
>> not.
>
> I think you're looking at it a bit too negatively. Yes, I was aware of the
> mfrow/mfcol/mfg problem (but not of the screen() problem), and yes, this is a
> real drawback. But not a showstopper, IMO.
>
OK. I'll try to rewrite the implementation, then. I'll turn off the
debug messages for now, so that others can still keep using the svn
code. I'll take some time in re-implementing it in a sane and
extendable way.
> Basically my philosophy is: Rather tolerate a duplicate plot in history than
> risk having one plot to few in history. Perhaps the user has used "Duplicate
> Device" precisely to make modifications to one copy, but to keep the other
> copy. Thus the copy would be logically different.
Good. This should avoid multiple replay ()s as well. The bottleneck
will be when history limit is reached. It has to be handled carefully,
now.
> But on a more general note: What should be the policy when two devices show
> the same history position, and the user modifies the plot in one? I suggest
> that the plot in the other device should remain untouched, but be considered a
> "new", not yet saved plot from now on. I.e.: Modifying a plot in one device
> window should never modify the plot in a separate device window. Once again,
> this is simply the safe thing to do, even if it may not always be exactly what
> the user expected.
>
> Well, as easy as that sounds in theory, it hinges on a reliable detection of
> when a plot has really changed. Currently we need to assume that the plot
> *may* have changed, any time the user navigates the history (among others).
> This would easily lead to a lot of confusion when using multiple devices.
>
> But perhaps it's not that hard after all? I just tried this with the X11Cairo
> device:
> plot(1, 1)
> a <- recordPlot()
> dev.off()
> replayPlot (a)
> b <- recordPlot()
> identical (a, b) # TRUE
> title ("something's changed")
> c <- recordPlot()
> identical (a, c) # FALSE
> I have not yet tested the windows() or quartz() devices, yet. But if the same
> thing works, there, this means we do have a reliable way to tell, whether a
> plot has been modified after all (only after calling recordPlot(), but still).
>
> So - does this sound like a feasible strategy?
Hadn't thought about that... Seems a safe enough strategy, although:
plot (1,1)
a <- recordPlot ()
dev.off () # even w/o dev.off ()
plot (1,1)
b <- recordPlot ()
identical (a,b) # FALSE
identical (a[[1]], b[[1]]) # TRUE
so, some of the raw bits are different! But 'b' is a new call anyway.
Off to the drawing board...
Regards
--
Prasenjit
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel
