Hi, Before implementing a history limit, I would like to ask your opinion on the following possible methods: (in order of decreasing simplicity)
Let L = length of history, S = memory size of history, s = memory size of single recorded plot. Here S and s will be approximate - as returned by object.size (). 1. Limit on L, no limit on either S or s -- naive 2. Limit on L and s which in turn limits S as well -- better than 1 but the user may not have a clear idea of how large s can be? 1 KB? 5 KB? 30 KB? 3. Limit on L and S -- can be easily superseded by just limiting on S. 4. Limit on S -- seems reasonable 5. Limit on S and s = p * S where p = (say) 0.6 -- more reasonable. The complexity comes next: what to do when the decided limit is reached? A. Ignore the new plots -- unreasonable B. Pop the old one(s) out and push the new one in -- reasonable 1+B and 2+B are easy to understand. I'll ignore 3+B. 4+B has the same issue as 5+B. 5+B: At every stage of adding a new plot, the number of plots being popped out of the history can be > 1 and this can be confusing. Here, p protects against "one huge plot wiping out the entire history." In case of B: all the "managed" devices have to be updated at every stage of pushing / popping. If a currently displayed plot on a device happens to be popped out, then the device has to be replayed by the next available plot in the history... Along with these, the toolbar icons have to be updated accordingly. These will not be difficult to implement, but I am just wondering about the overhead cost, if any! If the number of managed devices is small (which it is, in my personal usage - 3 or 4 max) then the cost will be minimal. But if, it increases to 10 or 15, then I am not sure of how much overhead cost this will create. (Recalling the thread on performance: http://thread.gmane.org/gmane.comp.statistics.rkward.devel/784 , although I am not sure if anyone would have 10 or 15 or more onscreen device windows open at the same time.) Opinions? Regards, -- Prasenjit ------------------------------------------------------------------------------ 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
