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
[rkward-devel] Feature request: going back to console sometimes blocked
Hello Indeed Thomas, with Launchpad system no excuse anymore not to get upgraded! Really so easy to install! Just installed and played a little bit with plot history, seems really useful!! I wanted to ask something else... I have this strange behavior that sometimes going back to console from script, you can't enter directly commands but need first to press esc. To do this: -enter a command, execute it -go to console, say select and copy a part of the result -go back to scrip -go back to console At this step, even if the cursor is in last line, you can't enter any command, need to press esc first. Do you confirm this behavour? In my opinion, it would be easier if going to console would always alow me to enter immediately command, do you agree? Is this not too complicated to implement? Thanks!! Matthieu -- 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
[rkward-devel] Dev snapshot 7 sep: bug with autosave
Hi Using the latest dev version from launchpad, I have now a problem when trying to save. I get following message: An error occured during while trying to create an autosave of the script file [file:name.R] Details: the file [name.R.rkward_autosave] does not exist. You can find screen print in: http://dl.dropbox.com/u/6113358/rkward%207%20sep%202010.png It just happened three times since the last two hours. Simply when trying to save the file. Best Matthieu -- 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] plot history featrues
Hi, overall this specification looks good to me. I do think there are some aspects which can safely be neglected for an initial implementation, however, in order not to introduce too much complexity too soon. I'll point out those, and add a few other comments. On Tuesday 07 September 2010, Prasenjit Kapat wrote: A. a global history - all managed screen devices will share it. B. ignore preview devices completely C. a STATIC global switch (checkbox) to enable / disable the plot history feature. STATIC means: toggling the checkbox will only affect new sessions of rkward, not the running ones - this global switch should be used to enable/disable the menu/toolbar actions as well Just an idea, haven't thought this through: Wouldn't it be enough to disable the record()-function (and clear any existing history) in order to effectively turn off the whole history? That could easily be switchable at runtime, then. Features: 1. history length restriction 2. duplicating a device: - behave as if the duplicated plot is new ie do not alter the old plot - when/if, possible to determine (reliably) that this new duplicated plot and old plot (duplicated from) are identical, do not save this new plot, otherwise always add it to the history at a new position I'd say the second bullet can safely be neglected for an initial implementation. Then no special treatment should be needed for dev.copy() at all, as it will simply behave like any other new plot. If we do go for hashes at a later point of time, no special treatment will be needed, either, as we can test for duplicates at any position in history very fast, then. 3. multiple plots on the screen: - check for par (mfig) and graphics:::.SSexists (sp.screens) While certainly desirable, this can probably be ignored for an intial implementation as well, IMO. 4. save the history list when rkward closes - not for this release - as part of the save workspace? - Windows uses .GlobalEnv::.savedPlots right from the beginning - when loading, replace the existing plot history by the loaded one? Agreed, not for this release. For any R objects in the workspace, the policy is to remove those, and then add the new ones. So I guess the existing plot history would be replaced in this case, too. Note that ?recordPlot cautions that bad things may happen if the plot was saved with another version of R. So we'd have to check for matching R version. 5. Actions: a. first / prev / next / last b. remove plot (has to be implemented due to 1.) c. append plot d. insert plot e. overwrite/replace plot (insert then remove) Insert, then remove would certainly do the trick, but also it could have side- effects of popping plots from history. So perhaps a separate treatment might make sense after all. As long as append plot exists, insert plot can probably wait, too. So if insert seems complex, I suggest ignoring it for now. f. clear history g. plot properties 5a. first / prev / next / last (and plot.new()/dev.off()) - always record - if the recorded version is not identical (see *1) to the old one and if the same plot is displayed on multiple devices, then save this recorded plot in place on the current device but set the status of the plots on all these other devices as new - if the number of these other devices 1, then no way to avoid duplicated plots (err on the conservative side!) (see *2) 5b. remove plot - if the user removes a plot from a device then replay the next available plot on this device Add a special case when the plot is automatically removed due to history length restriction. In this case, the current device does not show the removed plot (but rather the one to be saved), and does not need to replay anything. - if this removed plot is displayed on any other device(s) then set their status to new - again, if after removal, more than one other device displays the removed plot, then set these as new - no reliable way to avoid duplicated plots in the history (see *2) 5c. append plot - no matter what the current status is, this action should always append the displayed plot to the history - this is a safe guard action, ie, if some plot does not pass through the plot.new / print.trellis etc. wrappers then the user still has a way to add it to the history w/o loosing the plot 5d. Insert plot - similar to append, but the plot will be inserted in the history - care needs to be taken to avoid copying / moving the whole/part of the recorded history See above. Not required for an initial implementation as long as append plot exists. 5e. Clear history - after clearing, make the plots displayed on the devices as new 5f. Plot properties - for lattice calls, truncate the call string to a fixed length - additional status bar? since drop-down menu has been implemented, this may not be needed. - for graphics::: functions extract the last plot call from history, if at all possible - last
[rkward-devel] Snapshot 7 sep: new plot window too big
Hello I guess since new buttons have been added to the toolbar of the plot window, it comes on the screen too big, so that the lower right part is not on the screen and I can't reach it. I'm then not able to resize it as I want... Do you see this too? maybe it would be more comfortable if it comes with smaller size by default? Thanks Matthieu -- 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] plot history featrues
On Tuesday 07 September 2010, Thomas Friedrichsmeier wrote: The idea to use a hash is certainly appealing, but I'm also reluctant to add new hard dependencies. Using an optional dependency, sounds like adding a lot of complexity, though. Qt also supports MD5 and SHA1, so perhaps it's not too much trouble to cook a basic digest ourselves, instead. I'm not sure, how much impact this would have on the implementation. If it's just a detail, I'd say it's for a later release. If it's a core aspect, I'd say use digest() for now, and I'll look into creating hash function based on Qt. On second thought: plot (rnorm (1)) a - recordPlot() b - recordPlot () system.time (for (i in 1:1000) digest (a)) user system elapsed 6.244 0.100 6.367 system.time (for (i in 1:1000) identical (a, b)) user system elapsed 1.068 0.004 1.051 So, for the most common case, which is simply comparing the current plot against the one that was previously saved at this position in history, identical is six times faster than creating a hash. For the use case of checking the entire history for duplicates, using a hash would seem to be faster once more than six plots are involved, but: - If two plots really *are* different, identical() is much faster, and in fact it's typically close to instantaneous in this case. Thus, as long as there are no, or only few duplicates, using identical() is still the faster option. And we can safely assume few duplicates to be the more common case. - Checking the entire history for duplicates may (or may not?) have additional potential for confusion in some corner cases. It may well be a good idea, but I'd advise against it for the moment. Let's try to keep things simple for now. 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
[rkward-devel] bug report
Hi, im having problens with a script. The bug report says the following: Application: rkward (0.5.3) KDE Platform Version: 4.4.2 (KDE 4.4.2) Qt Version: 4.6.2 Operating System: Linux 2.6.32-24-generic-pae i686 Distribution: Ubuntu 10.04.1 LTS -- Information about the crash: In detail, tell us what you were doing when the application crashed. The crash can be reproduced every time. -- Backtrace: Application: RKWard (rkward.bin), signal: Aborted [Current thread is 1 (Thread 0xb46f8710 (LWP 1921))] Thread 2 (Thread 0xb1dfdb70 (LWP 1925)): [KCrash Handler] #6 0xb786c430 in __kernel_vsyscall () #7 0xb4f61651 in raise () from /lib/tls/i686/cmov/libc.so.6 #8 0xb4f64a82 in abort () from /lib/tls/i686/cmov/libc.so.6 #9 0xb4f9849d in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb4fa2591 in ?? () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4fa3de8 in ?? () from /lib/tls/i686/cmov/libc.so.6 #12 0xb4fa6ecd in free () from /lib/tls/i686/cmov/libc.so.6 #13 0xb658c0fd in ReleaseLargeFreeVectors (size_needed=value optimized out) at memory.c:784 #14 RunGenCollect (size_needed=value optimized out) at memory.c:1404 #15 R_gc_internal (size_needed=value optimized out) at memory.c:2248 #16 0xb658d758 in Rf_allocVector (type=14, length=4) at memory.c:2021 #17 0xb6523143 in duplicate1 (s=0xaa3ab830) at duplicate.c:214 #18 0xb6522d0c in duplicate1 (s=value optimized out) at duplicate.c:207 #19 0xb6523091 in duplicate1 (s=0xab3df35c) at duplicate.c:172 #20 0xb6523648 in Rf_duplicate (s=0xab3df378) at duplicate.c:115 #21 0xb659b2c1 in Rf_usemethod (generic=0xb66c2045 is.array, obj=0xaaf1d60, call=0xab3df378, args=0xab3df404, rho=0xab3df420, callrho=0x9e5693c, defrho=0x9e5693c, ans=0xb1dfbbfc) at objects.c:302 #22 0xb65520e3 in Rf_DispatchOrEval (call=0xab3df378, op=0x9e4c3a4, generic=0xb66c2045 is.array, args=0xab3df3b0, rho=0x9e5693c, ans=0xb1dfbbfc, dropmissing=0, argsevald=1) at eval.c:2080 #23 0xb64d0685 in do_is (call=0xab3df378, op=0x9e4c3a4, args=0xab3df3b0, rho=0x9e5693c) at coerce.c:1681 #24 0xb654afa3 in Rf_eval (e=0xab3df378, rho=0x9e5693c) at eval.c:493 #25 0x0815686a in _start () Thread 1 (Thread 0xb46f8710 (LWP 1921)): #0 0xb786c430 in __kernel_vsyscall () #1 0xb5011d33 in ?? () from /lib/tls/i686/cmov/libc.so.6 #2 0xb4fa8697 in ?? () from /lib/tls/i686/cmov/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) -- 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] bug report
Hi, On Tue, Sep 7, 2010 at 3:54 PM, Julio Lucio Lancelotti ju...@cenpat.edu.ar wrote: Hi, im having problens with a script. The bug report says the following: Application: rkward (0.5.3) KDE Platform Version: 4.4.2 (KDE 4.4.2) Qt Version: 4.6.2 Operating System: Linux 2.6.32-24-generic-pae i686 Distribution: Ubuntu 10.04.1 LTS -- Information about the crash: In detail, tell us what you were doing when the application crashed. The crash can be reproduced every time. Thanks for the report. Can you give a reproducible R code? or which R command is creating the crash? What is the version of R? -- Backtrace: Application: RKWard (rkward.bin), signal: Aborted [Current thread is 1 (Thread 0xb46f8710 (LWP 1921))] Thread 2 (Thread 0xb1dfdb70 (LWP 1925)): [KCrash Handler] #6 0xb786c430 in __kernel_vsyscall () #7 0xb4f61651 in raise () from /lib/tls/i686/cmov/libc.so.6 #8 0xb4f64a82 in abort () from /lib/tls/i686/cmov/libc.so.6 #9 0xb4f9849d in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb4fa2591 in ?? () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4fa3de8 in ?? () from /lib/tls/i686/cmov/libc.so.6 #12 0xb4fa6ecd in free () from /lib/tls/i686/cmov/libc.so.6 #13 0xb658c0fd in ReleaseLargeFreeVectors (size_needed=value optimized out) at memory.c:784 #14 RunGenCollect (size_needed=value optimized out) at memory.c:1404 #15 R_gc_internal (size_needed=value optimized out) at memory.c:2248 #16 0xb658d758 in Rf_allocVector (type=14, length=4) at memory.c:2021 #17 0xb6523143 in duplicate1 (s=0xaa3ab830) at duplicate.c:214 #18 0xb6522d0c in duplicate1 (s=value optimized out) at duplicate.c:207 #19 0xb6523091 in duplicate1 (s=0xab3df35c) at duplicate.c:172 #20 0xb6523648 in Rf_duplicate (s=0xab3df378) at duplicate.c:115 #21 0xb659b2c1 in Rf_usemethod (generic=0xb66c2045 is.array, obj=0xaaf1d60, call=0xab3df378, args=0xab3df404, rho=0xab3df420, callrho=0x9e5693c, defrho=0x9e5693c, ans=0xb1dfbbfc) at objects.c:302 #22 0xb65520e3 in Rf_DispatchOrEval (call=0xab3df378, op=0x9e4c3a4, generic=0xb66c2045 is.array, args=0xab3df3b0, rho=0x9e5693c, ans=0xb1dfbbfc, dropmissing=0, argsevald=1) at eval.c:2080 #23 0xb64d0685 in do_is (call=0xab3df378, op=0x9e4c3a4, args=0xab3df3b0, rho=0x9e5693c) at coerce.c:1681 #24 0xb654afa3 in Rf_eval (e=0xab3df378, rho=0x9e5693c) at eval.c:493 #25 0x0815686a in _start () Thread 1 (Thread 0xb46f8710 (LWP 1921)): #0 0xb786c430 in __kernel_vsyscall () #1 0xb5011d33 in ?? () from /lib/tls/i686/cmov/libc.so.6 #2 0xb4fa8697 in ?? () from /lib/tls/i686/cmov/libc.so.6 -- 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 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] bug report
Hi, Please include rkward-devel either in To or Cc when replying. On Tue, Sep 7, 2010 at 5:08 PM, Julio Lucio Lancelotti ju...@cenpat.edu.ar wrote: R.Version() $platform [1] i486-pc-linux-gnu $arch [1] i486 $os [1] linux-gnu $system [1] i486, linux-gnu $status [1] $major [1] 2 $minor [1] 11.1 $year [1] 2010 $month [1] 05 $day [1] 31 $`svn rev` [1] 52157 $language [1] R $version.string [1] R version 2.11.1 (2010-05-31) I have attached one of the script that generate the collapse. It collapse also using plain R Didn't get any attachment! Also, the fact that it collapses in plain R (assuming it is run from a terminal) says that there is something wrong with the script. Hence may not be related to rkward at all. In such a case, r-h...@stat.math.ethz.ch, is the list to go. 2010/9/7 Prasenjit Kapat kap...@gmail.com Hi, On Tue, Sep 7, 2010 at 3:54 PM, Julio Lucio Lancelotti ju...@cenpat.edu.ar wrote: Hi, im having problens with a script. The bug report says the following: Application: rkward (0.5.3) KDE Platform Version: 4.4.2 (KDE 4.4.2) Qt Version: 4.6.2 Operating System: Linux 2.6.32-24-generic-pae i686 Distribution: Ubuntu 10.04.1 LTS -- Information about the crash: In detail, tell us what you were doing when the application crashed. The crash can be reproduced every time. Thanks for the report. Can you give a reproducible R code? or which R command is creating the crash? What is the version of R? -- Backtrace: Application: RKWard (rkward.bin), signal: Aborted [Current thread is 1 (Thread 0xb46f8710 (LWP 1921))] Thread 2 (Thread 0xb1dfdb70 (LWP 1925)): [KCrash Handler] #6 0xb786c430 in __kernel_vsyscall () #7 0xb4f61651 in raise () from /lib/tls/i686/cmov/libc.so.6 #8 0xb4f64a82 in abort () from /lib/tls/i686/cmov/libc.so.6 #9 0xb4f9849d in ?? () from /lib/tls/i686/cmov/libc.so.6 #10 0xb4fa2591 in ?? () from /lib/tls/i686/cmov/libc.so.6 #11 0xb4fa3de8 in ?? () from /lib/tls/i686/cmov/libc.so.6 #12 0xb4fa6ecd in free () from /lib/tls/i686/cmov/libc.so.6 #13 0xb658c0fd in ReleaseLargeFreeVectors (size_needed=value optimized out) at memory.c:784 #14 RunGenCollect (size_needed=value optimized out) at memory.c:1404 #15 R_gc_internal (size_needed=value optimized out) at memory.c:2248 #16 0xb658d758 in Rf_allocVector (type=14, length=4) at memory.c:2021 #17 0xb6523143 in duplicate1 (s=0xaa3ab830) at duplicate.c:214 #18 0xb6522d0c in duplicate1 (s=value optimized out) at duplicate.c:207 #19 0xb6523091 in duplicate1 (s=0xab3df35c) at duplicate.c:172 #20 0xb6523648 in Rf_duplicate (s=0xab3df378) at duplicate.c:115 #21 0xb659b2c1 in Rf_usemethod (generic=0xb66c2045 is.array, obj=0xaaf1d60, call=0xab3df378, args=0xab3df404, rho=0xab3df420, callrho=0x9e5693c, defrho=0x9e5693c, ans=0xb1dfbbfc) at objects.c:302 #22 0xb65520e3 in Rf_DispatchOrEval (call=0xab3df378, op=0x9e4c3a4, generic=0xb66c2045 is.array, args=0xab3df3b0, rho=0x9e5693c, ans=0xb1dfbbfc, dropmissing=0, argsevald=1) at eval.c:2080 #23 0xb64d0685 in do_is (call=0xab3df378, op=0x9e4c3a4, args=0xab3df3b0, rho=0x9e5693c) at coerce.c:1681 #24 0xb654afa3 in Rf_eval (e=0xab3df378, rho=0x9e5693c) at eval.c:493 #25 0x0815686a in _start () Thread 1 (Thread 0xb46f8710 (LWP 1921)): #0 0xb786c430 in __kernel_vsyscall () #1 0xb5011d33 in ?? () from /lib/tls/i686/cmov/libc.so.6 #2 0xb4fa8697 in ?? () from /lib/tls/i686/cmov/libc.so.6 -- Prasenjit -- 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
