Re: [rkward-devel] Request for feedback on plot history
Hi, On Mon, Sep 6, 2010 at 11:10 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 06 September 2010, Stefan Rödiger wrote: The dropdown menu (What next? c) would be really helpful. Indicating the number of the plot and the fist bit of the commands used would be sufficient for me. Something like: 1 plot(rnorm(... 2 hist(data... ... for normal (non lattice) plots, showing the plot command is probably impossible, technically. Both the number and the actual calls are now part of the drop down list. (@Thomas: You have provided the important breakthroughs, again!) -- Prasenjit -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Request for feedback on plot history
Hi, On Monday 06 September 2010, Prasenjit Kapat wrote: Can we get the last command from history? in theory, yes, but not currently. (We do not support the R history mechanisms, yet, but it's in the feature tracker somewhere). Remember we are only interested in the primary plotting functions. Unfortunately, utils::history () calls file.show () in the end, so I don't think the paged output can be assigned to any variable. I was thinking of writing another history function (almost the same as utils::history) which would search for plot ()-type patterns, eg: ^(plot|hist|boxplot|...). This function would be called from our wrapped plot.new () just before record () call. A properly crafted regex pattern, can hunt down the first line of a multiline command as well. Note that the plot-call may not be in the history at all. The user may well have used a hand-written function (or one form some obscure package) that created the plot. And in fact a single top-level command may produce several totally different plots. An alternative could be to inspect sys.calls() inside plot.new(). Although it may not always be clear, just which call best describes the plot. Also of course, there's the problem that not all plots are created with plot.new(), again. Still I would think this will probably be a more reliable method. Again, this is just an idea. What do yo think? Will it work? Well, I'm not opposed against experimenting with this. But also, personally, I'm pretty happy with the current title-extraction, so I'd give this very low priority. Definitely not something to worry about before everything else working. Regards Thomas signature.asc Description: This is a digitally signed message part. -- 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
Re: [rkward-devel] Request for feedback on plot history
Hi, On Tue, Sep 7, 2010 at 3:17 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 06 September 2010, Prasenjit Kapat wrote: Can we get the last command from history? in theory, yes, but not currently. (We do not support the R history mechanisms, yet, but it's in the feature tracker somewhere). Remember we are only interested in the primary plotting functions. Unfortunately, utils::history () calls file.show () in the end, so I don't think the paged output can be assigned to any variable. I was thinking of writing another history function (almost the same as utils::history) which would search for plot ()-type patterns, eg: ^(plot|hist|boxplot|...). This function would be called from our wrapped plot.new () just before record () call. A properly crafted regex pattern, can hunt down the first line of a multiline command as well. Note that the plot-call may not be in the history at all. The user may well have used a hand-written function (or one form some obscure package) that created the plot. And in fact a single top-level command may produce several totally different plots. Yeah, history () will not work. Period. An alternative could be to inspect sys.calls() inside plot.new(). Although it may not always be clear, just which call best describes the plot. Also of course, there's the problem that not all plots are created with plot.new(), again. Still I would think this will probably be a more reliable method. Hmm.. a better idea than history, certainly. 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
Re: [rkward-devel] Request for feedback on plot history
Hi, On Sun, Sep 5, 2010 at 11:38 PM, Stefan Rödiger stefan_roedi...@gmx.de wrote: Am Dienstag 31 August 2010, 03:43:57 schrieb Prasenjit Kapat: Hi, Following this thread from Thomas: http://www.mail-archive.com/rkward-devel@lists.sourceforge.net/msg00872.htm l I would like to get some feedbacks, especially bugs. I used the latest SVN and found no bugs (I use the feature relative intensively during my work). Thanks for the testing, Stefan. I'm re-writing the whole thing, hopefully, for the better. I'll make another call for testing once done... To my pleasant surprise it works (move through history, remove elements, ...) without problems with split.screen() too. But trouble here is that I find it You were working with version before the recent overhaul. But still, every plot () -type call after split.screen () should create a separate entry into history. Let us not worry about it, for now. hard to tell which window is open without calling Plot properties manually (this issue would be addressed in future versions for non-splitted windows if I understand you right). Either Plot properties get a more prominent position (persistent status bar as you suggested) or you could establish some kind of visual feedback (see below Visual feedback, or other active GUI elements of RKWard have a read square for example) in future version. But this has no priority in my opinion. I see that Thomas has already added a drop-down list. I haven't tested that version yet. That should help in the visual feedback. One thing I find a bit distracting is the output presented in the console and command-log when a plot is invoked (example output attached). This is an issue for me since I use to work on a 10 inch netbook from time to time and therefore need to scroll more than I used to. Yeah, sorry for that, the output is mainly there for my debugging purpose. All the non-error outputs will be suppressed in the final version. 1. Settings Configure RKWard Output has settings for the history length and size Found it finally after this hint. I which there was a help button as in the plug-ins. Even in the current stat the plot history is quite powerful and some easy accessible documentation -as users of plug-ins might be used to- would be highly appreciated. Oh, yes! once the whole thing settles, I'll write the rkh file. The dropdown menu (What next? c) would be really helpful. Indicating the number of the plot and the fist bit of the commands used would be sufficient for me. Something like: 1 plot(rnorm(... 2 hist(data... ... This will be impossible to get for standard graphics functions (in package:graphics). But already there for the lattice functions. I have some ideas, but I don't think it is going to work. What next? a. Fix the Add to history action in a more intuitive way b. If possible, replace the info button by a persistent status bar Definitely (see above). My suggestion would include some more feedback within the plot region (red square, a plot number, ..., what ever) which would also help when working with a splitted screen. Do we need a status bar even after the plot history drop down menu? c. A drop down menu for the history? Definitely (see above) Thomas has already added that. Thanks again. BTW, hold off you plot-history related testing for a week now. I'm re-writing the whole thing. 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
Re: [rkward-devel] Request for feedback on plot history
HI, On Mon, Sep 6, 2010 at 11:10 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 06 September 2010, Stefan Rödiger wrote: The dropdown menu (What next? c) would be really helpful. Indicating the number of the plot and the fist bit of the commands used would be sufficient for me. Something like: 1 plot(rnorm(... 2 hist(data... ... I've added a drop-down menu (Prasenjit, I hope I did not get into your way Great! Now, I have all the more reason to finish up the new re-write quickly. with this; the changes in public_graphics.R are fairly straightforward, though). Of course for normal (non lattice) plots, showing the plot command is probably impossible, technically. Yes, for graphics:: () functions this will be impossible. Here is an idea, may not work though (and I am not going to try it until the main stuff is done): Can we get the last command from history? Remember we are only interested in the primary plotting functions. Unfortunately, utils::history () calls file.show () in the end, so I don't think the paged output can be assigned to any variable. I was thinking of writing another history function (almost the same as utils::history) which would search for plot ()-type patterns, eg: ^(plot|hist|boxplot|...). This function would be called from our wrapped plot.new () just before record () call. A properly crafted regex pattern, can hunt down the first line of a multiline command as well. Again, this is just an idea. What do yo think? Will it work? This is still buggy when you are navigating from a yet unsaved plot to a different position, when the history is already filled to the maximum length. It should be possible to fix this, but since it probably needs to make some assumptions about the internals of the implementation, I thought I rather wait for the next version before bothering with this. Yes, lets wait for the re-write. 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
Re: [rkward-devel] Request for feedback on plot history
Am Montag 06 September 2010, 13:10:26 schrieb Thomas Friedrichsmeier: Hi, On Monday 06 September 2010, Stefan Rödiger wrote: The dropdown menu (What next? c) would be really helpful. Indicating the number of the plot and the fist bit of the commands used would be sufficient for me. Something like: 1 plot(rnorm(... 2 hist(data... ... I've added a drop-down menu (Prasenjit, I hope I did not get into your way with this; the changes in public_graphics.R are fairly straightforward, though). Of course for normal (non lattice) plots, showing the plot command is probably impossible, technically. This is still buggy when you are navigating from a yet unsaved plot to a different position, when the history is already filled to the maximum length. It should be possible to fix this, but since it probably needs to make some assumptions about the internals of the implementation, I thought I rather wait for the next version before bothering with this. Worked fine for me. I had no crashes when I was doing some boxplots, jumping between them, ... . I changed the default the settings (8 instead of 20) plot history entries out of curiosity what might happen. Even that worked with the notification that some plots need to be removed when I apply the new settings. But I wonder how do you deal with multiple opened windows? All have one history or each has an individual? All windows share a single history, currently. This has some advantages (most importantly, the plot history persists after closing the device windwow!), but it's also the root cause of most of the headaches which Prasenjit and I have been discussing the past few days. Okay. Regards Thomas Regards Stefan -- 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
Re: [rkward-devel] Request for feedback on plot history
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. I mean, we are talking about corner cases to some degree in all these issues. The plain case works well, even for trellis plots, and the plot history feature adds real value in this case! We should try to achieve perfection over time, but R being the flexible beast that it is, it's pretty much impossible to create a fully perfect solution to any problem. The type of problem that we should be *very* careful to avoid is making something worse due to new features. E.g. the user losing plots, as could conceivable happen with the current implementation of the remove-feature. But here, we're talking about a use case where the plot history simply won't be of much use, currently, not where it would do any harm. Either way, I'd say, let's target a release in roughly 3-4 weeks. That will give us at least one more week to try to achieve a good basic solution for this feature. After that week we can discuss whether the remaining problems can be tolerated, or fixed in time for the release. Overall, this is a really cool feature, and I'd really like to make it part of the release! Getting rid of the remove action is not really an option, if we want to impose a history length restriction. So, even if the user is not provided with a visible remove action, it still has to be implemented internally. Yes. What I'm arguing is that remove should not alter any other device. If a plot is removed in device 2, and the same plot is still visible in device 3, let's just keep it in device 3, there. It should be purged from the history, but not from any other device besides 2. In device 3 it should now be considered new. I.e. removing a plot in one device window should never remove the plot in a separate device window. Yes, in some cases this might not be what the user intends, but it's quite simply the safe thing to do. Besides, we are - once again - talking about a corner case, here, not something that would happen to users a lot. Perhaps the same basic strategy applies for replacing plots, and for duplicated devices, but it's a bit tricker, there. More on that, somewhere below. Right, you have a valid point here. And it is tied to the inability to handle more than one new / unsaved plots. To be able to handle it, things will have to be implemented differently (I have an idea, similar to what I had earlier. But it will take some time and thinking to combine the two strategies together.) I'm don't know the details of your implementation the way you do, but wouldn't the following be enough to address this: - For new plots assume the special history position 0 (or NA, or whatever). - Once plots get recorded, they will be inserted into regular history positions as before. In case of several new plots, they will be inserted into the history one by one in the order of device numbers. - Naturally, .rk.graph.history.gui() will need to be made a bit smarter (or the C++ code). But probably it's enough to translate the special new position into history-length + 1 at this point. This was on my mind as well. And this is what windows does too, slightly differently. To implement it in a way so that the user can change it dynamically during a running rkward session will be tricky. But, to do it statically (ie needs to restart rkward) will be easy. I'll just have to, essentially, include the plot.new, dev.off, etc. wrappers inside an __if (getOption (rk.implement.plot.history))__ block. Well, I guess that would be good enough. This is just to be on the safe side, anyway. Fair enough. But it would be difficult to avoid a duplicated plot in history. For example consider duplicating device 2 to device 3 and the status of the plot on device 3 is set to new. Now, if the next command from the user is a primary function call (as opposed to a secondary one, such as: title, points, lines, grid, ...) such as: plot/persp/hist/xyplot/... then the plot which was copied from device 2 will get recorded to the history at a new position, yet, it will be the exact same plot as the already (?) recorded one from device 2. Just another source of confusion / surprise ;) Basically my
Re: [rkward-devel] Request for feedback on plot history
On Sunday 05 September 2010, Thomas Friedrichsmeier wrote: 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). Update: I have tested on windows(), now, and it works there, too. And identical (a, b) appears to be pretty fast. For a 1.6MB plot (i.e. above the default limit), it's around 10 msecs on my Centrino @ 2.0 GHz. Regards Thomas signature.asc Description: This is a digitally signed message part. -- 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
Re: [rkward-devel] Request for feedback on plot history
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
Re: [rkward-devel] Request for feedback on plot history
Am Dienstag 31 August 2010, 03:43:57 schrieb Prasenjit Kapat: Hi, Following this thread from Thomas: http://www.mail-archive.com/rkward-devel@lists.sourceforge.net/msg00872.htm l I would like to get some feedbacks, especially bugs. I used the latest SVN and found no bugs (I use the feature relative intensively during my work). Handling is overall intuitive IMHO. However, for a moment I didn't grasp the idea of the Activate button which turned out to be genial when I saw the screen cast. Definitely a Won't miss it. Everything else stated hereafter applies to for future versions as you stated yourself. To my pleasant surprise it works (move through history, remove elements, ...) without problems with split.screen() too. But trouble here is that I find it hard to tell which window is open without calling Plot properties manually (this issue would be addressed in future versions for non-splitted windows if I understand you right). Either Plot properties get a more prominent position (persistent status bar as you suggested) or you could establish some kind of visual feedback (see below Visual feedback, or other active GUI elements of RKWard have a read square for example) in future version. But this has no priority in my opinion. One thing I find a bit distracting is the output presented in the console and command-log when a plot is invoked (example output attached). This is an issue for me since I use to work on a 10 inch netbook from time to time and therefore need to scroll more than I used to. Here is a screenshot of the new screen device window: http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Screenshots#Gr aphics_history_actions_.28from_trunk.29 And here is a screencast (download the ogv file from here; could not upload it to any of the video sites): http://www.mediafire.com/?z3gp737xa5h1t (Meik: see [1] below) That helped to understand Quoting Thomas: Basically, please create a few plots in one or more windows, try the toolbar buttons, and comment on any aspect that is not intuitive, or buggy. stated above Some notes: 1. Settings Configure RKWard Output has settings for the history length and size Found it finally after this hint. I which there was a help button as in the plug-ins. Even in the current stat the plot history is quite powerful and some easy accessible documentation -as users of plug-ins might be used to- would be highly appreciated. 2. The arrow icons are self explanatory. Note that: if there is any new plot on the current device then it will be appended to the history before moving away. Works excellent. Suggestions: More visual feedback. I would like to see some information in the plot window. Something like (Plot 12, active window 3). I'm aware that Plot properties provides this information too and that you plan this for future versions. My suggestion, however is to show this information in the plot when scrolling through the plot history. The dropdown menu (What next? c) would be really helpful. Indicating the number of the plot and the fist bit of the commands used would be sufficient for me. Something like: 1 plot(rnorm(... 2 hist(data... ... This would help to keep track. It would also support the work when removing a plot from the history. But I wonder how do you deal with multiple opened windows? All have one history or each has an individual? 3. The Add to history (+) button will be confusing. For modified (using points () or lines () or ...) standard graphics plot, it will overwrite the existing plot; for everything else it will append to the history. I plan to fix this. Suggestions are welcome. Thomas had mentioned the following: http://www.mail-archive.com/rkward-devel@lists.sourceforge.net/msg00853.htm l 4. Remove from history is self explanatory True, nothing to add here (but see my suggestion above). 5. Clear history will clear the entire plot history, but you can still add the displayed plot back into the history using + icon 6. The Show info action currently uses kdialog (recently changed it from readline ()), but as soon as Thomas returns (and finds time to implement a dialog box connection on the C++ side) I plan to change it to a more native version. (Although, wherever rkward can run kdialog is available, even on windows. One just has to figure out the right path to it!) Simple and informative. Works for me. 7. Since his (Thomas's) mail, I have updated the svn code to include lattice plots in the plot history as well. (I use lattice very frequently.) Recording and replaying these plots is different from those of the standard graphics plots. The difference is exploitable in a useful way - the plot call can be extracted / displayed. So, if you use lattice, give it a try, esp. the Show Info action. What next? a. Fix the Add to history action in a more intuitive way b. If possible, replace the info button by a persistent
Re: [rkward-devel] Request for feedback on plot history
Hi, Thanks for the quick inputs, Thomas. To everyone: find if there is any high-level-primary plot function which does not get recorded (technically, which does not call plot.new ()). For example: persp () does not call plot.new (), but we have taken care of it by putting in a hook. Are there other such primary functions? (My fear is, yes!) Browse through __help(packages=graphics)__. In addition, plotting calls from completely other systems (such as, may be, ggplot2) which does not call either plot.new or print.trellis will get washed out completely. On Sat, Sep 4, 2010 at 8:00 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, gee, this whole affair sure is more complex than I would have imagined! 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 did not have a look at everything, so far, but here are a few issues and comments: The main problem in the current implementation (of recording at every first/prev/next/last.. action) is this: I can not handle a situation where two devices have unsaved plots. And hence I have to call record () over and over again, to make sure such a situation does not arise. Of course, similar thing happens when removing, which in turn, calls replay () over and over again. Getting rid of the remove action is not really an option, if we want to impose a history length restriction. So, even if the user is not provided with a visible remove action, it still has to be implemented internally. On Saturday 04 September 2010, Prasenjit Kapat wrote: All right, the current implementation records and replays liberally. In some cases, you can see the multiple replay processes. If it feels too sluggish, then we will have to drop the plot history feature for this release. One performance problem that I have hit occurs once the history limit is reached. Then, if you create a new plot (all on a single device!), what appears to happen is that the current plot is replayed. As far as I understand, this comes from remove(), and there pop.and.update(). This will always redraw plots in all current device windows, while actually the only windows that would really need an update are those whose plots have actually been popped. For the others it would be enough to just update the internal list of history positions. Not sure, how to do this, best, but I think this is the most severe performance problem ATM. Again, when looking into this, it might be worth considering whether a plot that has been popped out of the history should really be cleared from any other devices that show it. Perhaps it should rather gain the status of a new plot, instead, which has not yet been placed in the history. The use case I'm thinking of is this: 1) User creates a fancy plot in one device, wanting to keep it. 2) User opens a second device (so as not to overwrite the other plot), and starts creating a different plot in it. Since it's not that easy, it takes the user a good number of attempts to arrive at the desired result for this plot. Naturally, each attempt will take up a slot in the history... 3) As the history limit is reached, the plot created in 1 is popped out of the history, and is gone for good! Right, you have a valid point here. And it is tied to the inability to handle more than one new / unsaved plots. To be able to handle it, things will have to be implemented differently (I have an idea, similar to what I had earlier. But it will take some time and thinking to combine the two strategies together.) While talking about all this, it would probably be a good idea to offer some configuration option for turning off the whole history mechanism in case of unforseen problems. Again, I'm not sure, how to implement this, best. This was on my mind as well. And this is what windows does too, slightly differently. To implement it in a way so that the user can change it dynamically during a running rkward session will be tricky. But, to do it statically (ie needs to restart rkward) will be easy. I'll just have to, essentially, include the plot.new, dev.off, etc. wrappers inside an __if (getOption (rk.implement.plot.history))__ block. I have kept the replace plot feature because of trellis plots. All right. I suggest an additional insert plot for the wishlist, then. Use case: User wants to modify a plot, but wants to be able to revert to a previous state in case of mess up. So he inserts the previous state into the history, then proceeds
Re: [rkward-devel] Request for feedback on plot history
Hi, On Thursday 02 September 2010, Prasenjit Kapat wrote: On Wed, Sep 1, 2010 at 4:31 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Is it really a good idea to synchronize the plot windows that show the same history position? I.e. if two separate windows each show the first plot in history, and that is removed, should the other window really switch to the next plot, too? Or should that now be considered a fresh plot? I could see the merit in both, but the current behavior was somewhat surprising to me at first. Yeah, that was something on my mind too, but let us stick with this for now. It can be changed to something more intuitive later. In any case, the way I look at it is this: what you are removing is a plot from the history not just from the displayed device. I'll take a note of this and we can come back after 0.5.4. Yes, ok. Should dev.set() always set newPlotExists for the respective device to true? In case additions are made to that plot? E.g. produce a plot, add it to history, then add a grid to that plot, then use previous / next actions - grid is gone. Yes, that is an inherent problem with all the secondary base graphics functions: points, lines, abline, mtext, grid, title, axes, We would not, as of current implementation, know when such a function was called. At this stage the user should click the + button to save (overwrite and not append) the plot manually. Yes, I realized that after writing the mail. We simply have no chance to detect all such changes to existing plots in a fully realiable way. What I find unsatisfying about the current solution is that it's not really obvious when a plot will be recorded automatically, and when it will not be recorded automatically. I think the answer is it is recorded *the first time* we switch to another plot in any way (plot.new(), new device, prev/next buttons), but never again after that. I think this is simply very unintuitive, and can easily lead to annoying surprises. Ok, but then what? Here's two ideas: 1) *Never* save to the history automatically, but only when the user clicks +. The advantage of this solution is that there are no surprises. But it also takes away some of the usefulness of the plot history. Still it might be worth to offer this as an optional behavior (but perhaps not for the moment, to avoid adding too much complexity too soon)? 2) *Always* save to the history on plot.new, prev/next, etc. without the whole newPlotExists mechanism. The advantage is again that it offers much less potential for surprises. It does seem pretty wasteful, since most of the time, the plots are not actually modified, but we still record them again and again while browsing the history. On the other hand, recording plots appears to be pretty damn fast for anything that I have tried so far, while replaying plots is inherently slow. So any overhead that we add at this point will probably not be noticeable. Follow-up problem: Synchronization is probably needed in case of multiple device windows showing the same history position (this time potentially wasting a lot of CPU cycles, since it can mean a slow replay-operation; but then this case should only be triggered every once in a while). Well, I think 2) will be worth a try. (BTW, these may have implications for the behavior of the +-button, too. For solution 1, probably the current replace plot behavior makes most sense. For solution 2, replace plot is rather useless, and so it should really be insert plot.) Letting dev.set () always set newPlotExists to TRUE will force recording with each and every arrow movement (first/previous/next/last). I am a little reluctant in doing this. How much of an overload would that be? Would the browsing feel sluggish? May be not, I'll give it a try. So basically I'm suggesting the same thing, but the newPlotExists mechanism would then be obsolete, as far as I can see. One thing that I had in mind was to use the assignInNamespace trick for _all_ of these secondary functions; although it may work only for some and not all of them. But this approach seems kind of brute force! Yes, and it's asking for breakage, sooner or later. At latest, when a new secondary function is added. Probably makes more sense to add this info in a drop-down list of plots in the history (your point c). For the plot that is currently shown, info on titles, etc. is not really interesting. It is interesting for browsing the plots which are *not* currently visible, however. I can try to add something, but I'm not sure how soon. Precisely. I just wanted to have a stub which can be used later. If you so prefer, I can comment out the entire info codes for this release. I think it does not do any harm to keep it as is for now. Only the info button should be less visible for the release, IMO. Toolbar is crowded. I'd suggest to remove first/last plot, remove plot,
Re: [rkward-devel] Request for feedback on plot history
Hi, On Tuesday 31 August 2010, Prasenjit Kapat wrote: 6. The Show info action currently uses kdialog (recently changed it from readline ()), but as soon as Thomas returns (and finds time to implement a dialog box connection on the C++ side) I plan to change it to a more native version. (Although, wherever rkward can run kdialog is available, even on windows. One just has to figure out the right path to it!) I've just added functions rk.show.message(), and rk.show.question() to SVN. So you can replace those kdialogs, now. Let me know, if this needs more / different features / fixes. Regards Thomas signature.asc Description: This is a digitally signed message part. -- 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
Re: [rkward-devel] Request for feedback on plot history
Hi, I was playing around with the plot history feature of Windows (windows ()) and Mac OS X's (qaurtz ()), something that I shuold've done much earlier. They are both very minimalistic, although windows' is slightly better. I realized that we were shooting a near ideal solution, which is going to be next-to-impossible w/o breakage-prone hacks. On Thu, Sep 2, 2010 at 2:55 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: 2) *Always* save to the history on plot.new, prev/next, etc. without the whole newPlotExists mechanism. The advantage is again that it offers much less potential for surprises. It does seem pretty wasteful, since most of the time, the plots are not actually modified, but we still record them again and again while browsing the history. On the other hand, recording plots appears to be pretty damn fast for anything that I have tried so far, while replaying plots is inherently slow. So any overhead that we add at this point will probably not be noticeable. I think this is the only viable solution for now. I'll work on this in the next few days. BTW, Thomas: When / if time permits, can you download R-2.11-1.tar.gz and browse through src/library/grDevices/src/devWindows.c Of particular interest is the string xd-needsave (and also the displayList member) Can you figure out the logic as to when they are setting needsave to TRUE (~2139)? Or the other way: the logic when they are setting needsave to FALSE (~1135,1177,1882,2137) Is there anything helpful for us? This is again not for this release but for the bigger picture. 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
Re: [rkward-devel] Request for feedback on plot history
Hi, great work, overall! This is pretty sophisticated stuff, and that also means there's a lot of details to think about and test. I'm not sure I've seen everything, but I don't want to let you wait much longer. So here are the notes I have taken so far in no particular order. I'll post again, if / when I find more. -- Warning message: In push.pop.and.record(which.pop = 1, deviceId = deviceId, this.plot.is.new = TRUE) : Max length reached, popping out the first plot. Suggest to remove this one. After the limit is reached, you will see it for every single plot, which is probably more annoying than helpful. In contrast, the larger than size limit warning should only be triggered once in a while, so I think it is good to keep it. -- Is it really a good idea to synchronize the plot windows that show the same history position? I.e. if two separate windows each show the first plot in history, and that is removed, should the other window really switch to the next plot, too? Or should that now be considered a fresh plot? I could see the merit in both, but the current behavior was somewhat surprising to me at first. -- Should dev.set() always set newPlotExists for the respective device to true? In case additions are made to that plot? E.g. produce a plot, add it to history, then add a grid to that plot, then use previous / next actions - grid is gone. -- Extracting the title / axis labels: Cool stuff! I no longer thought this was possible at all. However, currently, the code bails out in case the title has been re-set using title(). In this case there is more than one .Primitive (title) in the recorded plot. Probably makes more sense to add this info in a drop-down list of plots in the history (your point c). For the plot that is currently shown, info on titles, etc. is not really interesting. It is interesting for browsing the plots which are *not* currently visible, however. I can try to add something, but I'm not sure how soon. Of course for lattice plots, the story may be different, as more info is potentially available. But then - personally - I think it would probably be a good idea to trim that down to some very basic information, too, which is probably titles and axis labels, again? Either way, we can leave this as is for the current release. -- Toolbar is crowded. I'd suggest to remove first/last plot, remove plot, clear history, and info buttons from the toolbar by default. -- Could you check the code for parts which are no longer needed and remove those? .verify.history.limits() appears to be one unused function. Regards Thomas signature.asc Description: This is a digitally signed message part. -- 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
Re: [rkward-devel] Request for feedback on plot history
Hi, On Wed, Sep 1, 2010 at 4:31 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, great work, overall! This is pretty sophisticated stuff, and that also means there's a lot of details to think about and test. I'm not sure I've seen everything, but I don't want to let you wait much longer. So here are the notes I have taken so far in no particular order. I'll post again, if / when I find more. Thanks for the inputs... I really need these... This whole plot history thing has lot of nuances, so the more feed back the better... Warning message: In push.pop.and.record(which.pop = 1, deviceId = deviceId, this.plot.is.new = TRUE) : Max length reached, popping out the first plot. Suggest to remove this one. After the limit is reached, you will see it for every single plot, which is probably more annoying than helpful. In contrast, the larger than size limit warning should only be triggered once in a while, so I think it is good to keep it. Done. BTW, the printPars () calls will also be commented out / removed before the final version. I'll keep it in till the Add to history feature is ironed out. Is it really a good idea to synchronize the plot windows that show the same history position? I.e. if two separate windows each show the first plot in history, and that is removed, should the other window really switch to the next plot, too? Or should that now be considered a fresh plot? I could see the merit in both, but the current behavior was somewhat surprising to me at first. Yeah, that was something on my mind too, but let us stick with this for now. It can be changed to something more intuitive later. In any case, the way I look at it is this: what you are removing is a plot from the history not just from the displayed device. I'll take a note of this and we can come back after 0.5.4. Should dev.set() always set newPlotExists for the respective device to true? In case additions are made to that plot? E.g. produce a plot, add it to history, then add a grid to that plot, then use previous / next actions - grid is gone. Yes, that is an inherent problem with all the secondary base graphics functions: points, lines, abline, mtext, grid, title, axes, We would not, as of current implementation, know when such a function was called. At this stage the user should click the + button to save (overwrite and not append) the plot manually. Letting dev.set () always set newPlotExists to TRUE will force recording with each and every arrow movement (first/previous/next/last). I am a little reluctant in doing this. How much of an overload would that be? Would the browsing feel sluggish? May be not, I'll give it a try. One thing that I had in mind was to use the assignInNamespace trick for _all_ of these secondary functions; although it may work only for some and not all of them. But this approach seems kind of brute force! Let me see what I can do. Extracting the title / axis labels: Cool stuff! I no longer thought this was possible at all. However, currently, the code bails out in case the title has been re-set using title(). In this case there is more than one .Primitive (title) in the recorded plot. Ah... how cruel is that! This can be fixed (partially). Probably makes more sense to add this info in a drop-down list of plots in the history (your point c). For the plot that is currently shown, info on titles, etc. is not really interesting. It is interesting for browsing the plots which are *not* currently visible, however. I can try to add something, but I'm not sure how soon. Precisely. I just wanted to have a stub which can be used later. If you so prefer, I can comment out the entire info codes for this release. Of course for lattice plots, the story may be different, as more info is potentially available. But then - personally - I think it would probably be a good idea to trim that down to some very basic information, too, which is probably titles and axis labels, again? Right, although I'll like to keep at least the main part of the call which shows the function and the formula used. Again, this can be delayed for the next version. Either way, we can leave this as is for the current release. See next comment. Toolbar is crowded. I'd suggest to remove first/last plot, remove plot, clear history, and info buttons from the toolbar by default. I would like to keep remove plot on the toolbar, others can go, no problem ;) Could you check the code for parts which are no longer needed and remove those? .verify.history.limits() appears to be one unused function. I'll check these. The verify.hist.limits () fn is used in settings/rksettingsmoduleoutput.cpp ~199 Thanks again, -- Prasenjit -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010.
