Re: [rkward-devel] memory management
On Sat, May 5, 2012 at 6:10 PM, meik michalke meik.micha...@uni-duesseldorf.de wrote: hi, over the past few days, i collected some amount of data, i.e. a script examined more than 120.000 XML documents. for a while this ran just fine, but at a certain point the machine ran out of RAM. i then included a manual call to gc() in the loop, which actually already removed all processed objects with rm() so i didn't think i'd run into problems, but that still didn't really help as much as i had thought. i just examined this a bit. calling gc() in RKWard *looks* like it really frees memory, but on the system level i don't notice a significant reduction. only after i close RKWard the memory level goes back considerably. can it be that the memory freed by R is still occupied by RKWard throughout a session? I just tried x - rnorm (10^8) # wait rm (x) invisible (gc ()) and I can see the memory usage fall in htop as well as /proc/meminfo. Here is essential part of /proc/meminfo: Before rnorm (): MemTotal:3914192 kB MemFree: 2325700 kB Buffers:9932 kB Cached: 211476 kB SwapCached: 279992 kB Active: 890012 kB Before gc () MemTotal:3914192 kB MemFree: 1558384 kB Buffers:9976 kB Cached: 211500 kB SwapCached: 279404 kB Active: 1656728 kB After gc () MemTotal:3914192 kB MemFree: 2340744 kB Buffers: 10004 kB Cached: 211532 kB SwapCached: 279480 kB Active: 875420 kB After closing rkward: MemTotal:3914192 kB MemFree: 2406108 kB Buffers: 10012 kB Cached: 211528 kB SwapCached: 279468 kB Active: 811044 kB viele grüße :: m.eik -- Prasenjit -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS FINAL
On Wed, Dec 29, 2010 at 6:06 AM, Stefan Rödiger stefan_roedi...@gmx.de wrote: The paper is submitted :) Fingers crossed. A special Thanks to Stefan for taking the initiative. The first draft is always the difficult one. The later polishing and updates takes time but can always be done. And also to Thomas for working on the initial drafts. Let's hope for the best. -- Prasenjit -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS FINAL
On Tue, Dec 28, 2010 at 12:46 PM, Stefan Rödiger stefan_roedi...@gmx.de wrote: Hi all, it's the 28th and I guess that's the final call. I won't correct anything else from my side and therefore take the latest version from SVN. Please state if you * need more time * are finished. Yes I am finished. I'll give it one more reading. If you don't get anything from me by 11.59 pm CET (28th), then I don't have anything! I still have an issue with: 5.6. Development process, there Newly developed plugins are placed in a dedicated plugin map called under development.pluginmap. appears to be to long. Can you confirm this? Yes, it is a bit long. I think it will be fine to remove the name of the plugin map file, it need not be spelled out: Newly developed plugins are placed in a dedicated plugin map file. Plugins in this map are not visible to the user by default, but need to be enabled manually. reads fine I think. If not, lets just go with the current long sentence and we can modify once the referees get back (assuming they do!). Next (29th 12:00 pm CET) I will send in the paper as PDF to JSS. From what I Yes, 12:00 pm == Noon; 12:00 am == Midnight ;) understand we get the issue number, things to change/correct etc. from JSS, in case we get accepted, and have to send it back thereafter. That is my understanding as well. -- Prasenjit -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS FINAL
On Tue, Dec 28, 2010 at 1:23 PM, Prasenjit Kapat kap...@gmail.com wrote: On Tue, Dec 28, 2010 at 12:46 PM, Stefan Rödiger stefan_roedi...@gmx.de wrote: Hi all, it's the 28th and I guess that's the final call. I won't correct anything else from my side and therefore take the latest version from SVN. Please state if you * need more time * are finished. Yes I am finished. I'll give it one more reading. If you don't get anything from me by 11.59 pm CET (28th), then I don't have anything! All right, I am done. -- Prasenjit -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS FINAL
On Sun, Dec 26, 2010 at 3:06 PM, Thomas Friedrichsmeier
thomas.friedrichsme...@ruhr-uni-bochum.de wrote:
4) If I get it right \proglang{} is only for languages (XML, HTML, R, C++,
Qt, ECMAScript, ...) not for programs like Red-R or RKWard (see 5)).
Yes, but it does not appear to be clear-cut. Citing from jss.dtx:
% This should be used for typesetting the names of programming
% languages, e.g., |\proglang{Java}|, |\proglang{C++}| or |\proglang{R}|.
% This applies also to programmable environments which also have a GUI
% like |\proglang{SAS}|, |\proglang{Stata}| or |\proglang{S-PLUS}|.
Programmable environments could certainly be stretched to include KDE, but
also Red-R, and RKWard. Still I guess it's best to restrict it as you suggest.
What is the case of Rgui.exe and Rgui.app? Should it get treated like
SAS/S-PLUS and hence \proglang-ed?
A separate question:
In Fig 12, we use QtScript but it is not mentioned anywhere else in
the text. Will it be better to replace QtScript by ECMAScript
(QtScript)?.
--
Prasenjit
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS FINAL
On Mon, Dec 27, 2010 at 11:54 AM, Stefan Rödiger stefan_roedi...@gmx.de wrote: On Monday 27 December 2010 15:40:21 Thomas Friedrichsmeier wrote: Hi, On Monday 27 December 2010, Stefan Rödiger wrote: On Sunday 26 December 2010 21:06:34 Thomas Friedrichsmeier wrote: Some more comments / answers: I need a vote for the section Help system too. I like the non-commented version better, too, but I've edited it some more. Good. This will make somebody happy. I wonder who would that be ;) -- Prasenjit -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS FINAL
On Mon, Dec 27, 2010 at 9:40 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 27 December 2010, Stefan Rödiger wrote: On Sunday 26 December 2010 21:06:34 Thomas Friedrichsmeier wrote: Two other things that I've stumbled across: - Section 3.5 refers to Figure 8 many pages ahead. I think it should get a separate screenshot, resembling 8A, but with no filename entered, yet. I am not sure if two very similar figures will be that useful. I understand that it is not generally a good practice to refer ahead, but in this case it should be fine. OR, we can remove 8A and refer to the new figure wherever we refer to 8A. OR, just go with two figures for now and wait for the reviewers comments. -- Prasenjit -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
[rkward-devel] archiving locally modified 0.4.9 branch
Hi, (Concerns mainly Thomas.) Recently my dept machines upgraded to RHEL 6 (KDE 4.3) and with that my dependence on 0.4.9 and KDE 3 is done for good. I had modified the release_branch_0.4.9 here and there, implementing the plot history feature, that too partially. It is (and will remain) in a works for me state. Now, will it be possible/acceptable to create another branch on SVN and upload whatever I have to it, for the sake of archiving, if not anything else? If yes, then I can run a make clean/distclean and then, either add all the files to the new branch or tar it all up and add the single .tar.gz file somewhere. Regards, -- Prasenjit -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS paper, round 2
Hi, Finally, I have my version in svn. It is in the commented_version/_pk.odt. I've mainly added few lines on the plot history feature and edited a few things here and there, nothing major. On first impression, this seems like a long draft. I have not seen any of the JSS papers. Any idea, how long these papers are typically? Do they allow color figures? Some journals ask the authors to pay for them. Do they allow footnotes? I am not sure how Stefan is planning, but we may need to create a tex version once we reach a stable enough draft to get a better idea of the length and format. Anyway lets see how it goes. Regards, -- Prasenjit -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS paper, round 2
On Sun, Dec 5, 2010 at 2:17 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On first impression, this seems like a long draft. I have not seen any of the JSS papers. Any idea, how long these papers are typically? Our draft is quite long, and I wouldn't be too surprised, if reviewers will tell us to reduce this a bit. However, looking at a couple of the recent papers (http://www.jstatsoft.org/v37) we don't seem to be completely off limits. Of course the question of what exactly the editors expect an article for the R GUIs special issue to look like is a good question. Well, reading their call for papers: http://www.jstatsoft.org/misc/CFP-JSS_SV-GUIs_in_R.pdf I think our article would go in R GUI example (desktop) The tough call would be deal with the figures: It should be readable on both screen and paper, plus how many, etc... Do they allow color figures? Some journals ask the authors to pay for them. For all I know, there is no printed version of the JSS at all, so this should not be an issue. Other articles do have color figures. Do they allow footnotes? I can't find any statement on footnotes, but other articles do have footnotes. I see. So, that makes life easier ;) I am not sure how Stefan is planning, but we may need to create a tex version once we reach a stable enough draft to get a better idea of the length and format. Well, the deadline for submission is December, 31st. So I guess we should aim to have a stable draft (i.e. complete content) next weekend, and start to focus on the conversion to tex and the fine points (spelling, language, style, etc.) directly after. Stefan, do you have a tentative schedule? Yes, I should be able to spend some time of such edits as well. -- Prasenjit -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] two minor annoyances
On Sun, Dec 5, 2010 at 2:21 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Sunday 05 December 2010, meik michalke wrote: no 1: on my machines i'm always told the file could not be opened (which is of course true, because we were just about to create it in this process). RKWard should just take the file name and create a new file in the end. I can confirm this on Debian/sid with the latest from trunk and KDE 4.4.5. And as meik said, not seen in the plot export dialog. no 2: if i mark the old in old_file.txt and start to type new, i'll end up with n_file.txtew, because after i typed the first letter the cursor automatically jumps to the end of the line. it should just stay where i put it. Confirmed. I'll try to remember to look into it. Did you just fix it in the trunk? I do not see it now. -- Prasenjit -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] two minor annoyances
On Sun, Dec 5, 2010 at 2:35 PM, meik michalke meik.micha...@uni-duesseldorf.de wrote: hi, am Sonntag 05 Dezember 2010 (20:21) schrieb Thomas Friedrichsmeier: no 1: on my machines i'm always told the file could not be opened (which is of course true, because we were just about to create it in this process). RKWard should just take the file name and create a new file in the end. is this on Windows by any chance? hell, no! :-D Otherwise, which version of KDE is that? kdelibs5 version 4.5.4-0ubuntu1~maverick1~ppa2. i've had this on earlier KDE versions as well, though (that is at least throughout all of KDE 4). i just never reported it, guess because i always forgot about it until the end of a session... i have never encountered this issue with any other application i can think of, and it does work as expected in other RKWard dialogs, e.g. exporting a plot. Can you see if it is fixed in the trunk? I think the problem was to not explicitly specify type=savefile in the plugin's xml files. (And by default it is openfile?) Regards -- Prasenjit -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] JSS paper, round 2
2010/12/1 meik michalke meik.micha...@uni-duesseldorf.de: hi, i'm really sorry i've been so off-track lately. amongst other work related stuff, i was quite busy preparing the release of another kind ;-) o http://angstalt.de/?c=werkes=museonl=en and the klausuR package is from now on hosted on RForge: o https://r-forge.r-project.org/projects/klausur/ Am Montag, 15. November 2010, um 17:12:54 schrieb Thomas Friedrichsmeier: I've added a basic outline for that as chapter 7. Of course it's not yet written. Volunteers? i'll have some time to spend this weekend and could write something (7.1 7.2). if that's early enough and someone can give me a vague estimate of how elaborate this should be in the end (in lines), i'll do it. busy schedule on my end as well (trying to finish up soon) .. i'll try to devote some time on this weekend as well... which is the latest version, btw? (sorry haven't been following the discussions lately). i can see couple of fils in the commented_version dir and one in the master_version. Regards -- Prasenjit -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
Hi, Sorry for the delay, I am not getting much time these days... On Tue, Oct 26, 2010 at 2:48 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: yes and no. libstdc++ is certainly needed (by all KDE apps), but it should already be included in the Qt / and or KDE libraries. Either this is not the case on your system, libstdc++ is NOT included in either of the two KDE installations on my machine! Yet, kwrite.exe / konqueror.exe starts up fine (dolphin.exe does start but gives some error of not being able to launch klauncher). On my system libstdc++ is only present in C:\MinGW\bin. Where is it on your system? (For compiling, my kde is in D:\KDE4 and for RKWard packaging, kde is in D:\RKWard_packaging\RKWard\KDE .) or MinGW somehow thought it was a good idea to link against libstdc++ dynamically, in addition to that. I guess this is the case. Which version of GCC is this? I used 4.4.0. Mine's 4.5.0 (as seen from g++.exe --version). Should a different version matter? After all the compilation was done with this MinGW as well. Note: C:\MinGW\bin is not in my %PATH%, I only add it in the make_release.bat file. I would be surprised, if it matters, but I'm trying to spot differences. So here's one that we could revisit, later. Yes, something that I'll have to comeback to and try. Not having C:\MinGW\bin in the %PATH% should not be the problem, or at least, if it was, the installer as compiled on my computer would not work on yours, either. If I add the following to rkward.bat SET OLD_PATH=%PATH% SET PATH=C:\MinGW\bin;%PATH% [.. actual part of rkward.bat ..] SET PATH=%OLD_PATH% Then, rkward does start. The directory is fine as well - rkward.bin.exe is in D:\RKWard_package\RKWard\KDE\bin which is where all the libkde* exist. Just for testing: Does it work, if you install to the KDE-installation you used for building, instead? If it does, then we'll know we should look out for problems with the KDE installation rather than the build. No, the error is same, it is still looking for libstdc++ Here, I've a question. For packaging, I installed the end user (not the package manager) version of KDE (mingw flavor). I only checked kdebase-apps (Bin) and let it install the dependencies. Is that OK? Yes, that should do the trick. To make sure you really got the correct flavor, take a look at the manifest-directory in there. This should contain kdelibs- mingw4-4.4.x-bin.mft, among many others. Looking in mine, I see that I have kdewin-mingw4-4.3.2-bin.mft, however that got there. I guess you will have kdewin-mingw4-0.5.2-bin.mft, instead? Might be something to look at, too, but I don't think it's the cause of the problem. Yes, I do have, kdewin-mingw4-0.5.2-bin.mft -- Prasenjit -- Achieve Improved Network Security with IP and DNS Reputation. Defend against bad network traffic, including botnets, malware, phishing sites, and compromised hosts - saving your company time, money, and embarrassment. Learn More! http://p.sf.net/sfu/hpdev2dev-nov ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] RKWard on Windows
Hi Stefan, On Thu, Oct 28, 2010 at 3:53 PM, Stefan Rödiger stefan_roedi...@gmx.de wrote: Moreover I used to work with R.2.11 but switched to R2.12 today which resulted in a non starting RKWard. I did a reinstallation of RKWard and pointed to the new location of R. I did not check if the is a config file which can be changed if need or such. My point is that this might be a minor problem for average users. ... I am surprised that rkward compiled w/ R 2.11 works with R 2.12 by just changing the location of R. Anyway, I've been trying to setup a build environment on Windows.. I was hoping to compile against R 2.12.. I am not able to spent much time.. I'll look into this again over the weekend. Thanks, -- Prasenjit -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
Hi, So, I have tried doing this from scratch and things (seem to) have gone well. After installing RKWard, when attempting to start it using rkward.bat I get the following error: The application has failed to start because libstdc++-6.dll was not found. Re-installing the application may fix this problem. Now, libstdc++-6.dll is located at C:\MinGW\bin but should it be needed at runtime for RKWard? -- Prasenjit -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
On Mon, Oct 25, 2010 at 7:09 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 25 October 2010, Prasenjit Kapat wrote: The application has failed to start because libstdc++-6.dll was not found. Re-installing the application may fix this problem. Now, libstdc++-6.dll is located at C:\MinGW\bin but should it be needed at runtime for RKWard? yes and no. libstdc++ is certainly needed (by all KDE apps), but it should already be included in the Qt / and or KDE libraries. Either this is not the case on your system, or MinGW somehow thought it was a good idea to link against libstdc++ dynamically, in addition to that. Which version of GCC is this? I used 4.4.0. Mine's 4.5.0 (as seen from g++.exe --version). Should a different version matter? After all the compilation was done with this MinGW as well. Note: C:\MinGW\bin is not in my %PATH%, I only add it in the make_release.bat file. Could you double check that rkward.bat points to the correct location of rkward.bin.exe, that rkward.bin.exe is in the same directory as libkdeui.dll Yes the path is fine - I turned on ECHO and verified (using the actual rkward.bat file, not its shortcut). The directory is fine as well - rkward.bin.exe is in D:\RKWard_package\RKWard\KDE\bin which is where all the libkde* exist. Here, I've a question. For packaging, I installed the end user (not the package manager) version of KDE (mingw flavor). I only checked kdebase-apps (Bin) and let it install the dependencies. Is that OK? and friends, and that other KDE appications in that directory can be run? Yes, kwrite.exe, konqueror.exe, and dolphin.exe, from that directory (not the KDE used for compiling RKWard), run fine. What is the content of [...]\windows_nsis\build\rkward\CMakeFiles\rkward.bin.dir\link.txt after building? Here's mine: And here's mine (looks similar to yours): C:\MinGW\bin\g++.exe-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -D_WIN32_IE=0x0501 -DUNICODE -Woverloaded-virtual -fno-threadsafe-statics -O2 -DNDEBUG -DQT_NO_DEBUG -mwindows CMakeFiles\rkward.bin.dir\rkward.bin_automoc.obj CMakeFiles\rkward.bin.dir\rkward.obj CMakeFiles\rkward.bin.dir\main.obj CMakeFiles\rkward.bin.dir\rkglobals.obj CMakeFiles\rkward.bin.dir\robjectviewer.obj CMakeFiles\rkward.bin.dir\rkconsole.obj CMakeFiles\rkward.bin.dir\rkwardapplication.obj -o rkward.bin.exe -Wl,--out-implib,librkward.bin.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -LD:\KDE4\lib -LC:\R\R-2.11.1\bin -LD:\RKWard_devel\release_branch_0.5.4\windows_nsis\build\bin D:\KDE4\lib\libqtmain.a D:\KDE4\lib\libkdecore.dll.a ..\bin\libwindows.a ..\bin\libqwinhost.a ..\bin\libagents.a ..\bin\libdialogs.a ..\bin\libplugin.a ..\bin\libsettings.a ..\bin\libdataeditor.a ..\bin\libcore.a ..\bin\libscriptbackends.a ..\bin\librbackend.a ..\bin\libmisc.a -lktexteditor D:\KDE4\lib\libkhtml.dll.a D:\KDE4\lib\libkfile.dll.a D:\KDE4\lib\libkdeui.dll.a D:\KDE4\lib\libkrosscore.dll.a D:\KDE4\lib\libQtScript4.a -lR -lRlapack -lRblas D:\KDE4\lib\libkparts.dll.a D:\KDE4\lib\libkjs.dll.a D:\KDE4\lib\libkio.dll.a D:\KDE4\lib\libQtNetwork4.a D:\KDE4\lib\libkdeui.dll.a D:\KDE4\lib\libkdecore.dll.a D:\KDE4\lib\libQtDBus4.a D:\KDE4\lib\libQtCore4.a D:\KDE4\lib\libkdewin.dll.a -luser32 -lshell32 -lws2_32 -lnetapi32 -luserenv D:\KDE4\lib\libQtGui4.a D:\KDE4\lib\libQtSvg4.a D:\KDE4\lib\libQtXml4.a -- Prasenjit -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
On Thu, Oct 14, 2010 at 3:05 AM, Thomas Friedrichsmeier
thomas.friedrichsme...@ruhr-uni-bochum.de wrote:
On Thursday 14 October 2010, Prasenjit Kapat wrote:
mingw32-make[2]: *** No rule to make target `U:/lib/libkdewin.dll.a',
needed by `rkward/rkward.bin.exe'. Stop.
mingw32-make[1]: *** [rkward/CMakeFiles/rkward.bin.dir/all] Error 2
mingw32-make: *** [all] Error 2
Is U:/lib/... hard coded somewhere?
Yes, it's a known (and long standing bug). See this mail:
http://mail.kde.org/pipermail/kde-windows/2009-April/003655.html . You need to
fix all occurrences (two or three, IIRC), manually, in
KDEDIR\share\apps\cmake\modules .
So, this is only in
KDEDIR\share\apps\cmake\modules\KDELibs4LibraryTargets-release.cmake
(~lines 20 and 36), right?
And it suffices to replace U: by ${_IMPORT_PREFIX}, right?
The compilation seems to proceed w/o errors now. The move statement
spits out this error:
D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildmove
D:\RKWard_devel\release_branch_0.5.4\windows_nsis\/install/Program
Files/R/R-2.11.1
D:\RKWard_devel\release_branch_0.5.4\windows_nsis\/install/_RHOME_
The system cannot find the path specified.
I see that the directory created is actually this:
D:\RKWard_devel\release_branch_0.5.4\windows_nsis\install\ProgramFiles\R\R-2.11.1
Note: ProgramFiles instead of Program Files in the path. So does
this mean I need to install R to a path w/o spaces? Not a problem,
I'll just start over.
--
Prasenjit
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
On Wed, Oct 13, 2010 at 4:01 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Wednesday 13 October 2010, Prasenjit Kapat wrote: So this needs perl as well? yes, apparently. I find I have perl installed and in my path. Sorry about all this mess. I should have documented this while actively fumbling my way through all of this, instead of over a year later... no problem.. i haven't played around with KDE on Windows, so I do not have much idea on requirements and dependencies.. i'll try to document stuff on the wiki as i progress... CMake Error at D:/RKWard_devel/KDE4/cmake/modules/FindKDE4Internal.cmake:485 (include): include could not find load file: D:/RKWard_devel/KDE4/cmake/modules/KDELibsDependencies.cmake [...] Strange. I have FindKDE4Internal.cmake at [KDE]/share/apps/cmake/modules. This is also where those failed includes are on my system. Could you try adding -DKDE4_DATA_DIR=D:/RKWard_devel/KDE4/share/apps to the cmake options? will do. (And move the contents of [KDE]/cmake/modules into [KDE]/share/apps/cmake/modules.) will try that.. but that should, ideally, not be done, right? -- Phonon includes NOT found! CMake Error at D:/RKWard_devel/KDE4/cmake/modules/FindPhonon.cmake:63 (message): Phonon library or includes NOT found! I guess that means you'll have to add phonon (devel), too. will try this as well. -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
On Wed, Oct 13, 2010 at 4:01 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Wednesday 13 October 2010, Prasenjit Kapat wrote: CMake Error at D:/RKWard_devel/KDE4/cmake/modules/FindKDE4Internal.cmake:485 (include): include could not find load file: D:/RKWard_devel/KDE4/cmake/modules/KDELibsDependencies.cmake [...] Strange. I have FindKDE4Internal.cmake at [KDE]/share/apps/cmake/modules. This is also where those failed includes are on my system. Could you try adding -DKDE4_DATA_DIR=D:/RKWard_devel/KDE4/share/apps to the cmake options? Adding DKDE4_DATA_DIR solved the cmake errors, didn't have to do the following hack: (And move the contents of [KDE]/cmake/modules into [KDE]/share/apps/cmake/modules.) The cmake process went fine, almost. Here is the last error: [ 99%] Building CXX object rkward/CMakeFiles/rkward.bin.dir/rkconsole.obj In file included from D:\RKWard_devel\KDE4\include/kio/jobclasses.h:30:0, from D:\RKWard_devel\KDE4\include/kurlcompletion.h:27, from D:\RKWard_devel\KDE4\include/kshellcompletion.h:26, from D:\RKWard_devel\release_branch_0.5.4\rkward\rkconsole.cpp:38: D:\RKWard_devel\KDE4\include/kio/global.h:39:27: warning: type attributes ignored after type is already defined [ 99%] Building CXX object rkward/CMakeFiles/rkward.bin.dir/rkwardapplication.obj D:\RKWard_devel\release_branch_0.5.4\rkward\rkwardapplication.cpp:42:2: warning: #warning TODO: We could really use the detection logic from windows for x11, too. It seems much easier. mingw32-make[2]: *** No rule to make target `U:/lib/libkdewin.dll.a', needed by `rkward/rkward.bin.exe'. Stop. mingw32-make[1]: *** [rkward/CMakeFiles/rkward.bin.dir/all] Error 2 mingw32-make: *** [all] Error 2 Is U:/lib/... hard coded somewhere? -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
On Tue, Oct 12, 2010 at 4:12 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Monday 11 October 2010, Prasenjit Kapat wrote: CMake Error at D:/RKWard_devel/KDE4/share/cmake-2.6/Modules/FindPackageHandleStandardArgs .cmake:57 (MESSAGE): Did not find automoc4 (part of kdesupport). Searched for Automoc4Config.cmake in using suffixes automoc4 lib/automoc4 lib64/automoc4. (missing: AUTOMOC4_EXECUTABLE) Call Stack (most recent call first): [...] Now, automoc4 was supposed to be part of KDESupport Where did you get it from? I found this thread: http://kmess.org/board/viewtopic.php?f=3t=3360 Does that look reasonable? I don't want to compile against a random binary off the net! I don't recall downloading individual files from the net. I do seem to recall there may have been problems with some dependencies not being installed automatically. Check for the following packages (make sure, you are using Package Manager mode): - automoc The problem is that there is no automoc available through the installer! - kdelibs (check the devel box) - qt (check the devel box) - kdewin (check the devel box) yes to all the three. Hope that covers it. Unfortunately it does not. I'll try to grab automoc4 from one of the official kde mirrors and see. -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
On Tue, Oct 12, 2010 at 12:34 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Tuesday 12 October 2010, Prasenjit Kapat wrote: I seem to have version 4.3.2 installed, so this one should work for you, too: http://www.winkde.org/pub/kde/ports/win32/repository-4.3/kde/automoc- mingw4-4.3.2-bin.tar.bz2 . You can simply unpack that in the KDE installation root. So this needs perl as well? (version mismatch, too?) D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildcmake D:\RKWard_devel\release_branch_0.5.4\windows_nsis\\.. -G MinGW Makefiles -DCMAKE_INSTALL_PREFIX=d:/RKWard_devel\KDE4 -DR_EXECUTABLE=C:/Program Files/R/R-2.11.1/bin/R.exe -DR_LIBDIR=C:/Program Files/R/R-2.11.1/library -DCMAKE_BUILD_TYPE=Release -- Found Qt-Version 4.6.2 (using D:/RKWard_devel/KDE4/bin/qmake.exe) -- Found Automoc4: D:/RKWard_devel/KDE4/bin/automoc4.exe -- Could NOT find Perl (missing: PERL_EXECUTABLE) -- Perl not found CMake Error at D:/RKWard_devel/KDE4/cmake/modules/FindKDE4Internal.cmake:485 (include): include could not find load file: D:/RKWard_devel/KDE4/cmake/modules/KDELibsDependencies.cmake Call Stack (most recent call first): D:/RKWard_devel/KDE4/share/cmake-2.6/Modules/FindKDE4.cmake:81 (FIND_PACKAGE) CMakeLists.txt:10 (FIND_PACKAGE) CMake Error at D:/RKWard_devel/KDE4/cmake/modules/FindKDE4Internal.cmake:499 (macro_ensure_version): MACRO_ENSURE_VERSION Macro invoked with incorrect arguments for macro named: MACRO_ENSURE_VERSION Call Stack (most recent call first): D:/RKWard_devel/KDE4/share/cmake-2.6/Modules/FindKDE4.cmake:81 (FIND_PACKAGE) CMakeLists.txt:10 (FIND_PACKAGE) CMake Error at D:/RKWard_devel/KDE4/cmake/modules/FindKDE4Internal.cmake:513 (include): include could not find load file: D:/RKWard_devel/KDE4/cmake/modules/KDELibs4ToolsTargets.cmake Call Stack (most recent call first): D:/RKWard_devel/KDE4/share/cmake-2.6/Modules/FindKDE4.cmake:81 (FIND_PACKAGE) CMakeLists.txt:10 (FIND_PACKAGE) -- Adding d:/rkward_devel/kde4/share/apps/cmake/modules to CMAKE_MODULE_PATH CMake Error at D:/RKWard_devel/KDE4/cmake/modules/FindKDE4Internal.cmake:557 (include): include could not find load file: D:/RKWard_devel/KDE4/cmake/modules/KDELibs4LibraryTargets.cmake Call Stack (most recent call first): D:/RKWard_devel/KDE4/share/cmake-2.6/Modules/FindKDE4.cmake:81 (FIND_PACKAGE) CMakeLists.txt:10 (FIND_PACKAGE) -- Phonon includes NOT found! CMake Error at D:/RKWard_devel/KDE4/cmake/modules/FindPhonon.cmake:63 (message): Phonon library or includes NOT found! Call Stack (most recent call first): D:/RKWard_devel/KDE4/cmake/modules/FindKDE4Internal.cmake:613 (find_package) D:/RKWard_devel/KDE4/share/cmake-2.6/Modules/FindKDE4.cmake:81 (FIND_PACKAGE) CMakeLists.txt:10 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
On Fri, Oct 8, 2010 at 5:42 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Friday 08 October 2010, Prasenjit Kapat wrote: Ok, probably it's best to add PATH=%KDEPREFIXDRIVE%/%KDEPREFIX%/bin;%PATH% to make_release.bat, then, to make sure the KDE directory is in the path during compilation. Yes, I added C:\MinGW\bin to PATH as well. -DR_LIBDIR=C:/Program Files/R/R-2.11.1/library [...] D:/RKWard_devel/release_branch_0.5.4/windows_nsis/build/Files/R/R-2.11.1/l ibrary does not exist. Looks like a problem with the space in the C:\Program Files. You could try putting quotes around the define in the cmake command line, i.e. -DR_LIBDIR=%RHOMEDRIVE%/%RHOME%/library Yes, adding the quotes work, at least for now. The second one is mingw32-make - which (KDE) package has this? It is not in mingw-utils! I presume I'll need the mingw compiler as well from sourceforge? Oh well, all those steps I just forgot, blissfully. Yes, I had to download MinGW manually from mingw.sf.net. Not sure, whether their installer works, At least mingw32-make is found, now. these days. An alternative approach is to get it using emerge: http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/emerge . This is the new error: D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildcmake D:\RKWard_devel\release_branch_0.5.4\windows_nsis\\.. -G MinGW Makefiles -DCMAKE_INSTALL_PREFIX=d:/RKWard_devel\KDE4 -DR_EXECUTABLE=C:/Program Files/R/R-2.11.1/bin/R.exe -DR_LIBDIR=C:/Program Files/R/R-2.11.1/library -DCMAKE_BUILD_TYPE=Release -- Found Qt-Version 4.6.2 (using D:/RKWard_devel/KDE4/bin/qmake.exe) CMake Error at D:/RKWard_devel/KDE4/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57 (MESSAGE): Did not find automoc4 (part of kdesupport). Searched for Automoc4Config.cmake in using suffixes automoc4 lib/automoc4 lib64/automoc4. (missing: AUTOMOC4_EXECUTABLE) Call Stack (most recent call first): D:/RKWard_devel/KDE4/cmake/modules/FindAutomoc4.cmake:56 (find_package_handle_standard_args) D:/RKWard_devel/KDE4/cmake/modules/FindKDE4Internal.cmake:350 (find_package) D:/RKWard_devel/KDE4/share/cmake-2.6/Modules/FindKDE4.cmake:81 (FIND_PACKAGE) CMakeLists.txt:10 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildREM sh.exe must not be in path during cmake call, but must be in path for R package install... D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildSET PATH=d:\RKWard_devel\KDE4\bin;C:\MinGW\bin;C:\Program Files\PC Connectivity Solution\;C:\Program Files\Microsoft DirectX SDK (April 2007)\Utilities\Bin\x86;C:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Common Files\GTK\2.0\bin;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Universal Extractor;C:\Program Files\Universal Extractor\bin;C:\Program Files\TortoiseSVN\bin;D:\texlive\2009\bin\win32;C:\Program Files\R\Rtools\bin D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildmingw32-make install DESTDIR=D:\RKWard_devel\release_branch_0.5.4\windows_nsis\/install mingw32-make: *** No rule to make target `install'. Stop. Now, automoc4 was supposed to be part of KDESupport Where did you get it from? I found this thread: http://kmess.org/board/viewtopic.php?f=3t=3360 Does that look reasonable? I don't want to compile against a random binary off the net! -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] rkwardtests package: done :-)
On Thu, Oct 7, 2010 at 2:59 PM, meik michalke meik.micha...@uni-duesseldorf.de wrote: hi, am Donnerstag 07 Oktober 2010 (18:30) schrieb Thomas Friedrichsmeier: Hm, do you have the file /usr/lib/R/bin/roxygen ? Possibly a problem with multiple installations of R? Check wether which R is the one you expect (this one keeps tricking me again and again...). i didn't install the roxygen package system wide, but to $HOME/R, amongst a lot of other packages. i don't want to mess with system directories handled by dpkg, so anything i fetch directly from a CRAN repository stays in my $HOME. usually this works great, but R CMD roxygen seems to care only about $RHOME and ignore $R_LIB and $R_LIB_USER :-/ A quick thought: would using Rscript work then? It may not work on Windows though. In the worst case, writing a separate R script and calling R CMD BATCH might be a round-about solution. -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
Hi, On Thu, Oct 7, 2010 at 3:05 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Thursday 07 October 2010, Prasenjit Kapat wrote: What version of KDE do you use? I was trying with 4.4.4 (only other option is 4.2.2) - it does not install subverson, although it is listed, packages for konsole, dolphin, kwrite (kate is there though) are missing. I used 4.4.4 for compiling (upgraded form some earlier version, though). Regarding subversion, I don't remember any details, but I do recall I once searched for a windows svn client, manually, so it's quite possible that the one from the KDE installer did not work for me, either. kwrite should be in kdebase-apps. konsole does not work on windows, as far as I know (I use this to lessen the pain: http://sourceforge.net/projects/console/ ; it's still a windows command-line, though). I'm not sure about dolphin, but probably in kdebase-apps, too. I see. I was trying as minimal a selection as possible. I'll include apps next time. I'll try some other native subversion client. Any suggestions? Again, I don't recall, which one I downloaded. But this looks about right to me: http://www.sliksvn.com/en/download . Alternatively, TortoiseSVN seems to be a very popular graphical client. I'll give these a try and see. Would the regular rkward-xxx.tar.gz source work (ie not needing to pull from svn)? It doesn't have the windows_nsis-subdirectory needed to create a package (and no make_release.bat-script, either). I though so as well. BTW, reading the wiki, I assume I need to install the KDE packages twice - once for actually compiling RKWard, which installed system wide, and later while packaging up as 7zip file, which is installed inside the RKWard directory. Is this right? -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Windows packaging
Hi, On Sun, Oct 3, 2010 at 1:51 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Quite likely something is missing here or there, so let me know what goes wrong. Can you explain the variables in make_release.bat? I've edited the wiki, check and if needed fix them there. Now, I had to provide the full path to cmake: %KDEPREFIXDRIVE%\%KDEPREFIX%\bin\cmake (instead of just cmake) in make_release.bat file; because, the KDE4\bin dir is not in the %PATH%. Now, from the windows_nsis dir when I run make_release.bat, after all the SET statements, this what I get: (Note: D:\RKWard_devel\release_branch_0.5.4\windows_nsis\build is just the prompt) D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildd:\RKWard_devel\KDE4\bin\cmake D:\RKWard_devel\release_branch_0.5.4\windows_nsis\\.. -G MinGW Makefiles -DCMAKE_INSTALL_PREFIX=d:/RKWard_devel\KDE4 -DR_EXECUTABLE=C:/Program Files/R/R-2.11.1/bin/R.exe -DR_LIBDIR=C:/Program Files/R/R-2.11.1/library -DCMAKE_BUILD_TYPE=Release CMake Error: The source directory D:/RKWard_devel/release_branch_0.5.4/windows_nsis/build/Files/R/R-2.11.1/library does not exist. Specify --help for usage, or press the help button on the CMake GUI. D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildREM sh.exe must not be in path during cmake call, but must be in path for R package install... D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildSET PATH=C:\Program Files\PC Connectivity Solution\;C:\Program Files\Microsoft DirectX SDK (April 2007)\Utilities\Bin\x86;C:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Common Files\GTK\2.0\bin;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Universal Extractor;C:\Program Files\Universal Extractor\bin;C:\Program Files\TortoiseSVN\bin;D:\texlive\2009\bin\win32;C:\Program Files\R\Rtools\bin D:\RKWard_devel\release_branch_0.5.4\windows_nsis\buildmingw32-make install DESTDIR=D:\RKWard_devel\release_branch_0.5.4\windows_nsis\/install 'mingw32-make' is not recognized as an internal or external command, operable program or batch file. The execution proceeds, with errors, but let us ignore those for now. The first error is a cmake error - why is it looking for the R library inside the build dir? The second one is mingw32-make - which (KDE) package has this? It is not in mingw-utils! I presume I'll need the mingw compiler as well from sourceforge? -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Downloadable plugins
Hi On Wed, Oct 6, 2010 at 1:29 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Wednesday 06 October 2010, meik michalke wrote: i've just commited the first steps towards a working R package. it doesn't really work yet, but it's close ;-) i've placed it under rkward/rbackend/rpackages/rkwardtests. Alright. I've arranged for it to be installed with make install. i found roxygen to be pretty cool for documenting a package, keeping NAMESPACE up to date etc. unfortunately, you need it as a dependecy (though not loaded for a package). it could probably be stripped from the package afterwards. Yes, this looks like a very nice way of creating documentation, indeed. But in fact, we should not bring that dependency into the release (otherwise, the rkwardtests-package will not even install, unless the user already has roxygen installed). Yes, that is a nice style: similar to how Matlab provides documentation at the beginning of their .m files. What exactly do you need to do in order to generate the .Rd pages? Perhaps we could come up with a nifty script that adds the roxygen-dependency, generates the man pages, and removes the roxygen-dependency, again. We could then add that to scripts/makedist.sh. One thing we have to be careful is that make / make install should work even without an internet connection. (Or is it safe to assume that wherever / whoever is installing RKWard has access to the internet?) for the package, i split the original framework R file into one long file with stuff that is used internally only (and not documented), and one R file for each class, method or function that needs to be exported. the latter already have basic documentation in roxygen style. perhaps you could check if i made the right decisions on that behalf so far. I've only taken a cursory look, but seems good to me. I haven't looked, but AFAIK, we do not have a NAMESPACE for rkward package, right? So, there is no issue of exporting. But I would like to have a namepsace and export only those functions which are in public*.R. Regards, -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] browser() call will freeze rkward?
Hi, On Wed, Oct 6, 2010 at 12:07 AM, Prasenjit Kapat kap...@gmail.com wrote: Hi, On Tue, Oct 5, 2010 at 10:10 AM, Matthieu Stigler matthieu.stig...@gmail.com wrote: Le 05. 10. 10 09:42, Thomas Friedrichsmeier a écrit : On Monday 04 October 2010, Matthieu Stigler wrote: I have problems with the newest version of rkward, when I use a browser() call within a function, the cursor is then freezing and strangely, the workaround is to switch to another program and come back, then the cursor will be available. Try at least two times (does not happen first time, and not always subsequent times), something like: I tried your example several times with R 2.11.1 and R 2.12.0beta, but could not observe any freezing. I can not reproduce this either. Tried multiple times. mhh.. did you type n in the opened browser? I did. Which version of R? Linux / Windows? R 2.11.1, with Ubuntu 10.4, Kde 4.4.2 On my end, R 2.11.1, Debian/sid KDE 4.4.5 Forgot to mention: RKWard: updaed svn version. I'll try it with the released version and let you know. -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] browser() call will freeze rkward?
On Wed, Oct 6, 2010 at 12:13 AM, Prasenjit Kapat kap...@gmail.com wrote: Hi, On Wed, Oct 6, 2010 at 12:07 AM, Prasenjit Kapat kap...@gmail.com wrote: Hi, On Tue, Oct 5, 2010 at 10:10 AM, Matthieu Stigler matthieu.stig...@gmail.com wrote: Le 05. 10. 10 09:42, Thomas Friedrichsmeier a écrit : On Monday 04 October 2010, Matthieu Stigler wrote: I have problems with the newest version of rkward, when I use a browser() call within a function, the cursor is then freezing and strangely, the workaround is to switch to another program and come back, then the cursor will be available. Try at least two times (does not happen first time, and not always subsequent times), something like: I tried your example several times with R 2.11.1 and R 2.12.0beta, but could not observe any freezing. I can not reproduce this either. Tried multiple times. mhh.. did you type n in the opened browser? I did. Which version of R? Linux / Windows? R 2.11.1, with Ubuntu 10.4, Kde 4.4.2 On my end, R 2.11.1, Debian/sid KDE 4.4.5 Forgot to mention: RKWard: updaed svn version. I'll try it with the released version and let you know. Couldn't reproduce it with the 0.5.4 released version as well. -- Prasenjit -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] package info page immediately destroyed?
Hi Matthieu, On Sun, Sep 26, 2010 at 6:48 AM, mat matthieu.stig...@gmail.com wrote: Hello When I type help(package=stats), this opens a new info windows, which will not stay long time: soon, I get the message that file /tmp/... has been suppressed by another application and asks whether I want to save/ignore/cancel. Is this a normal behavior? Yes, for now. This happens whenever R uses a temporary disk file to show some information. You just have to hit Ignore and Continue (may be check the Don't remind me box along the way) Regards, -- 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] rkh file for utility functions
Hi, On Sat, Sep 25, 2010 at 6:52 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Saturday 25 September 2010, Prasenjit Kapat wrote: I've added a rk.list.plugins (...) to public.R, I hope it is not adding a new feature. well, it's sort of a new feature, but the important point is that it looks safe to add without breaking anything. While documenting rk.call.plugin, I felt that the user generally will have no idea of what goes as the first argument (plugin). True. And also, of course, the user generally will have no idea of what the available arguments are for a particular plugin. Right. This is will be a more important limitation. Well, rk.call.plugin() is mostly a by-product of the Run again link, and the automated tests. I'm not sure whether there is a real use-case for it beyond that (and I've added some words of caution to the .Rd-file), but potentially it might be interested for scripting tutorial or similar purposes. Actually in this respect, I felt, some of these functions can go in internal*.R as well. We may want to document them (and other functions) as part of internal*.R functions which will be helpful for those users who want to take the next step: contribute: either plugins / docs / core C++ side etc... These doc / help files need not be exposed to the regular users. If you prefer, I can add a pages/rkward_for_rkward_devs.rkh and move these links there? Then, move these functions back into internal.R? Is there any way to improve this? Right now, I am just scanning the pluginmap files... Can the C++ side list all the available plugins? Yes, and I've changed it to use that. However, the C++-side does not keep Yeah, I always felt had to be a better solution than reading and parsing the files from disk. I wanted to have some solution (albeit a dumb one) before asking you ;) track of where the plugin was declared, so this feature is lost. Note that both versions of rk.list.plugins() also list plugins which are not really meant to be called from the top-level, i.e. including those designed for embedding, or context-sensitive plugins like the graphics export-plugin. Yeah this kind of brings back the argument of moving these into internal.R, or at least move the help links to a rkward_for_rkward_devs.rkh page. Regards, -- 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] Potential Data editor bug
Hi, On Sun, Sep 26, 2010 at 1:46 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Thus, I am rather reluctant to do this. I would assume that duplicate column names are a rare exception, and so we can afford not to support them 100%. Do you think they are important enough as a use-case to make a better effort? Not really. In fact, I was under the impression, till I saw Stefan's example, that R does not allow same column names as it does not allow same row names... It was a surprise to me. Displaying column numbers in the GUI should be no problem. Where would you like to see them? Hmm, may be on top of the column headers or below, no particular preference. Regards, -- 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] rkh file for utility functions
Hi, On Sun, Sep 26, 2010 at 1:10 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Sunday 26 September 2010, Prasenjit Kapat wrote: Yeah this kind of brings back the argument of moving these into internal.R, or at least move the help links to a rkward_for_rkward_devs.rkh page. yes, perhaps that is a good idea to create such a rkward_for_rkward_devs page, so as not to make these too prominently visible. I'd leave moving them to internal.R for after the release, though. No reason to risk comitting copy- and-paste mistakes at this point. All right, I'll add that page tonight. Probably we want more than just internal.R, and public.R. I guess internal.R should be for functions which will only ever be called by the C++-code, or used by other functions. Beyond that we may want to sort into functions dealing with output, automated testing, etc. (similar to the way you split the .Rd-files, perhaps). Indeed, some thing to do after the release. Also, when looking at the documentation (and again, thanks for creating this!) I also have the strong feeling, that some of these functions can probably be merged, or removed, completely. But that will require great care, naturally. Also, one would need to keep in mind that if we were to provide a rkward package on CRAN (although, I somehow don't like the idea) then it should behave independently, ie, all help links and functions should be self contained. Regards, -- 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] rkh file for utility functions
Hi, Thomas: Can you take a look at rk.sync.Rd and rk.call.plugin.Rd, esp the TODO places. I've added a rk.list.plugins (...) to public.R, I hope it is not adding a new feature. While documenting rk.call.plugin, I felt that the user generally will have no idea of what goes as the first argument (plugin). Is there any way to improve this? Right now, I am just scanning the pluginmap files... Can the C++ side list all the available plugins? If not, is there any automatic way to know the path argument there? Regards, -- 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] rkh file for utility functions
Hi, On Sun, Sep 19, 2010 at 10:49 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: I think using an R style documentation might be a good idea after all. First, Does it now look closer to what you have in mind? (It is incomplete still...) Regards, -- 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 new plugin features, and plot history
Hi, On Sun, Sep 19, 2010 at 11:22 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: For post release (unless Thomas wants this implemented pre-release) features: I would suggest allowing more variables to be selected for ordering the data frame. Yes, true. The follow-up problem is that you may want to sort for A ascending and for B descending. Thus it should be possible to specify the sort order for each of the variables, separately. And we simply don't have a way to support this in the plugin GUI for an arbitrary number of variables, yet. Well, this is solvable, but not trivial. And it's what kept me from adding this right away. It would not work as a single call to order () then. It will have to loop over the selected variables individually. -- 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 new plugin features, and plot history
Hi, On Tue, Aug 3, 2010 at 7:55 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: The second area that I would like to pick your brains about is some new plugin features. Perhaps you recall this short thread on how to deal with plugins that do data.frame specific transformations: http://www.mail- archive.com/rkward-devel@lists.sourceforge.net/msg00779.html . The development snapshots have some variants of a solution for that. To try it, frist make sure that the under_development.pluginmap is activated under Settings- Configure RKWard-Plugins. You should see a new top-level menu called Data. In this, there are two variants of a Sort data plugin, and you will want to try each a) while you are editing a data.frame, and the data.frame is the active window and b) while any other window is active. As you will see, in case b), both plugins will seem identical. In case a), the active data.frame is preselected in both plugins, but the first variant still allows to select a different data.frame to sort. Key questions on that: - Which variant of the plugin is preferrable? To me the first variant is more transparent. The plugin remains same and whether or not a data frame is pre-selected is what changes. - Do you think it is intuitively clear, when a data.frame is active? Suggestions for improving this? For post release (unless Thomas wants this implemented pre-release) features: I would suggest allowing more variables to be selected for ordering the data frame. I generally use the following function to sort data frames: sortframe - function (.df., ...) .df. [do.call (order, list (...)), ] # eg: # my.data - with (my.data, sortframe (my.data, var1, var2)) We could call it rk.sort.data.frame and add it to public.R. Regards, -- 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
[rkward-devel] rkh file for utility functions
Hi, As some of you may have seen from the trunk, I have started to add some documentation for the functions in public.R and public_graphics.R. I am writing the documentation as a rkh file which can be accessed from F1 RKWard for Users Utility functions. Is a rkh file the right way to go about this? A proper R style (Rd) documentation would not be useful I suppose. Any other suggestions? BTW, I'll add as many functions as I can understand, and create stubs for the rest. Regards, -- 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] Potential Data editor bug
Hi, On Thu, Sep 16, 2010 at 2:44 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Thursday 16 September 2010, Stefan Rödiger wrote: BTW, as you might consent the lines attached in my example are not a good example how to work with R (size and arrangement of data ...). Thus it was really interesting for me to see what happens ... . I think the crucial thing in your example is that there are some duplicate names in the data.frame: Right. Sorry for the wrong flag earlier. There are three objects called D09. I don't think we can reasonably support this in the editor (probably the editor should just drop two of these variables), but of course it should not crash. Here is something that I found interesting. Consider the last two lines of Stefan's Procedure.txt: data - data.frame ( names (data) - c(... The crash is deterministic after you run these two lines individually (ie, Run current line). But the crash does NOT occur after you run them together (ie, Run selection) or after you run the whole file (ie Run all) or after _source (Procedure.txt)_. Stefan can you confirm this? Although, in many attempts I could not reproduce the crash using any of the following toy examples: Eg 1: data - as.data.frame (matrix (rnorm (3636), 101, 36)) names (data) - rep (A, 36) Here 101 and 36 were chosen based on Stefan's variable lengths. Eg 2: data - as.data.frame (matrix (1:70,10,7)) names (data) - c(A,B,C,A,D,E,A) Eg 3: data - data.frame (A=1:10, B=11:20, C=21:30, A=31:40, D=41:50, E=51:60, A=61:70) names (data) - c(A,B,C,A,D,E,A) Eg 4: A=1:10; B=11:20; C=21:30; D=41:50; E=51:60 data - data.frame (A,B,C,A,D,E,A) names (data) - c(A,B,C,A,D,E,A) When editing these, note that the order of the D and E columns as displayed in the data editor are swapped; which happens with Stefan's example as well (E07/F07 and C07/G07). I was just trying to create another reproducible (toy) example. As a caution to the user: Should a warning be displayed when the data editor encounters multiple columns with same name? Noting that, the data itself is not lost, it is just not displayed and hence not safe to be edited! (Or is it safe anyways?) Regards, -- 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] Potential Data editor bug
On Thu, Sep 16, 2010 at 8:22 AM, Stefan Rödiger stefan_roedi...@gmx.de wrote: Hi, I have two files attached. First is called procedure.txt with the description how to preduce the potential bug. And there is also the gdb message. I was able to reproduce the crash of RKWard multiple times by doing this. Confirmed. But if you use mydata instead of data as the data.frame variable then the crash does not occur. I guess the data editor is trying to edit utils::data as opposed to .GlobalEnv::data? Regards, -- 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] Snapshot 7 sep: new plot window too big
On Mon, Sep 13, 2010 at 10:22 AM, mat matthieu.stig...@gmail.com wrote: Le 09. 09. 10 15:25, Thomas Friedrichsmeier a écrit : On Thursday 09 September 2010, Matthieu Stigler wrote: please find in: /home/fao/Dropbox/Public/CaptureRkwardPlot.png For reference for others, here's the public url: http://dl.dropbox.com/u/6113358/CaptureRkwardPlot.png Ok, so the plot window is too high to fit into the available space at all. If the toolbar would be hidden, the window would probably fit, but of course hiding the toolbar by default is not a good solution. As far as I can see, the icons are as small as possible, already, and turning off the text labels would save width, but not height. a print scrren of my problem. Basically, just plotting on rkward 0.4.5-test5 (KDE 4.4.2), I can/t see the xlab, nor am I able to resize the window,as the lower right part is not accessible. But maybe I am just stupid and there is an obvious way to solve this in general? Well, the size of the plot window can be controlled in R. See ?x11. To use a smaller size by default, you can run X11.options (width=5, height=5) (width and height need to be specified in inches). I suppose we could offer a graphical option for this in the settings, but it's a bit tricky, since it will need some platform-specific code. So not before 0.5.4 is released, at least. oh that's a pitty! I tried on my laptop with newest version (Ubuntu 10.4,and rkward 4.4.2) , and the problem is still there! Would be great if this could avoided in next release (just by default reduce window size?) as this correspond in some way for me to a regression in rkward features! thanks! mat I see that Thomas has added a new settings in Configure Onscreen device. Can you try the svn code if it helps? @ Thomas: the width and height are declared as 'int'. By choice? I don't mind it, I am just curious. -- 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] some separate queries related to the plot history feature
HI, On Mon, Sep 13, 2010 at 7:45 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Sunday 12 September 2010, Prasenjit Kapat wrote: Yeah, the lattice plots are tracked through trellis.last.object () and not recordPlot () and for that reason rk.activate.device () should be used instead of dev.set (). I'll update the test code later, after adding a few more tests. I changed the test a bit more, but only to make it easier to read, not changing any of the logic (I think). I still get a mismatch the first time a trellis plot (plots[[2]]) is checked. I tried it twice now. Didn't see any mismatch.. But I'll keep an eye on it. If possible, I'd like to get rid of rk.activate.device() before the release. I.e. could you implement the wrapper around dev.set(), instead, as discussed? I suppose this will require replacing dev.set() with .rk.dev.set.default() at some places in the history-implementation, but I'm not quite sure, where, and where not. I'll try to fix that soon-ish. Btw, I see that you have moved the settings. But the old ones are still there! I didn't remove them, in case you kept them for some testing purposes! Regards, -- 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] some separate queries related to the plot history feature
On Tue, Sep 14, 2010 at 4:22 AM, Thomas Friedrichsmeier
thomas.friedrichsme...@ruhr-uni-bochum.de wrote:
On Tuesday 14 September 2010, Prasenjit Kapat wrote:
I tried it twice now. Didn't see any mismatch.. But I'll keep an eye on it.
Interesting. I keep getting this:
mark 1
Current plot does not match with plots[[2]]
mark 2
mark 3
mark 4
mark 5
mark 6
mark 7
mark 8
mark 8a
mark 9
mark 10
R 2.11.1, lattice 0.18-3
On my end, R 2.11.1 and lattice 0.19-11 (r-cran-lattice form deb
repo). Before upgrading lattice, could you try to remove rkward and
then re-install
Rscript -e remove.packages ('rkward')
make install
and see if it helps?
Regards,
--
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] some separate queries related to the plot history feature
Hi, On Sun, Sep 12, 2010 at 1:36 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Another thing: I just added a test to rkward_application_tests.R. Basically this opens two devices and calls some of the history actions. Then it checks whether the current plots are the expected ones. Somehow, when I try to mix in trellis plots (e.g. for plots 2 and 4), the test starts to fail. I have not really investigated, exactly what goes wrong, though. Perhaps you can have a look, too? There was a bug, fixed it. I've updated the plugin tests file as well. BTW, in the test file, using fname - rk.get.tempfile.name () gives the following error: [2] Error in paste(prefix, extension, sep = \\) : [3]argument \prefix\ is missing, with no default so I had to use rk.get.tempfile.name (image, jpg). But the function IS defined with defaults! Also, occasionally, the dev.off () fails so does dev.copy (..) saying invalid state of the graphics device.. This may be my nvidia related issue. -- 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] Interview on RKWard on dot.kde.org
On Mon, Sep 13, 2010 at 11:18 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi! Just in case you don't have enough to read, already: Recently, I've been interviewed about RKWard for KDE.news. The interview is now online at http://dot.kde.org. Nice! Good to associate a face with the name ;) For easier access later, here is the direct link: http://dot.kde.org/2010/09/13/kde-science-thomas-friedrichsmeier-rkward-toolkits-and-kde-platform -- 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] some separate queries related to the plot history feature
Hi, On Sun, Sep 12, 2010 at 9:08 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, BTW, I encountered some surprising behavior: When you add a plot using Append this plot, the plot-call appears to be lost. Appending in any other way makes the plot-call is shown as expected. Is this intentional or a bug? It should not get lost! Do you see 'NA'? It should at least use the old behavior of 'X: xlab, Y: ylab, main'. Now the code may not always be able to find xlab / ylab / main from the recorded plot. For example, the structure of a recorded (recorded using recordPlot ()) lattice plot is completely different from base graphics: xyplot (0~0) a - recordPlot () str (a) # insanely huge pairlist structure In such cases the old hack for extracting xlab / ylab / main will not yield anything. The Append this plot is supposed to be a safe guard action: append _any_ displayed plot no matter what its state / type is, using recordPlot (). For example, any call that does not go through, plot.new () / persp () / print.trellis () should still be appended to the history by this action. In such cases it may not possible, at least not with the current implementation, to extract any information at all. Regards, -- 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] plot history: 3rd attempt: request for feedback
Hi, On Sun, Sep 12, 2010 at 9:18 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, I didn't find too much time to test, but what I've seen so far looks good, both in terms of speed and correctness. I've found some rather minor issues and corrected those in SVN, but nothing serious. Thanks. I was wondering, if we should remove the Plot properties action completely? With the drop down list implemented, is it needed any more? There are two extra bits of information there: (1) size of the current plot and (2) complete plot call. Now, (1) may be useful to the user, given that we have implemented size restriction. But (2) may not be useful at all. What do you think? I did not look at the code in any detail so far, and will wait with that until you remove all the debugging calls (whenever you feel comfortable with that). Assuming there are no major issues / bugs, say till Wednesday (testing phase)? Admittedly, on first glance this looks a bit scary for the sheer amount of code, and I hope some of this can be simplified a bit. But that's for later. Part of the reason is that I chose to handle lattice calls separately, unlike windows ()' or quartz ()' implementation! Which I think, others may / may not agree, is a big feature. Along with that, the modularity should help in adding more features if / when needed. The important thing is that this implementation seems to work well, and we can improve it incrementall, later - as far as possible. Sure. In terms of speed, the crucial step was to disengage the devices avoiding multiple replay calls. My earlier implementation of synchronizing the devices seems a bit naive now! Regards, -- 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] plot history: 3rd attempt: request for feedback
On Sat, Sep 11, 2010 at 9:42 AM, Prasenjit Kapat kap...@gmail.com wrote: I have added a checkbox to enable/disable the history. Settings RKWard Output. Just a thought or future update: should this be implemented as a check box under the history menu (as in Windows) instead of the Settings? But then, it would be difficult to connect it to the Settings module! Regards, -- 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] some separate queries related to the plot history feature
Hi, On Sun, Sep 12, 2010 at 3:41 PM, Prasenjit Kapat kap...@gmail.com wrote: On Sun, Sep 12, 2010 at 2:41 PM, Prasenjit Kapat kap...@gmail.com wrote: Another thing: I just added a test to rkward_application_tests.R. Basically Thanks. this opens two devices and calls some of the history actions. Then it checks whether the current plots are the expected ones. Somehow, when I try to mix in trellis plots (e.g. for plots 2 and 4), the test starts to fail. I have not really investigated, exactly what goes wrong, though. Perhaps you can have a look, too? Yeah, the lattice plots are tracked through trellis.last.object () and not recordPlot () and for that reason rk.activate.device () should be used instead of dev.set (). I'll update the test code later, after adding a few more tests. How do I run only this test? Never mind, I just copied the function and testing it independently. Regards, -- 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] Snapshot 7 sep: new plot window too big
On Wed, Sep 8, 2010 at 2:28 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: One thing I note is that the toolbar does not appear to remember a changed icon-size setting. I'll have to look into it. Toolbar on the device window... Yeah, the settings are lost... -- 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 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] some separate queries related to the plot history feature
HI,
On Sat, Sep 11, 2010 at 1:03 PM, Thomas Friedrichsmeier
thomas.friedrichsme...@ruhr-uni-bochum.de wrote:
Hi,
On Friday 10 September 2010, Prasenjit Kapat wrote:
2. Are the message boxes of fixed height but variable width? Some of
the multiline text gets eaten up after 5/6 lines. But I guess, one
should not narrate stories via message boxes ;)
I've run into problems with KMessageBox layout, before. Apparently a problem
in kdelibs.
I have not stumbled across the affected message boxes in the plot history,
yet.
What do I need to do to see them?
None of the static messages will show such an error. But say if you call:
xyplot (0~0,
panel = function (...) {
panel.xyplot (...)
panel.abline (h=0,v=0)
})
Then, the showInfo box will be a few line shosrt
3. We will need to wrap dev.set and dev.copy.. Otherwise, an
independent user call of
dev.copy (device = x11, ...)
will not amount to the duplicate device behavior... But before
doing so, we'll have to be careful to avoid recursion.
Won't the regular approach work? I.e. replace with a wrapper, which calls
the real dev.copy()/dev.set(). Since the real dev.set() will not call the
wrapper, no recursion.
You mean the assignInNamespace?
4. Is it possible to assign icons to the message boxes? (This is not
at all important though)
In theory, yes, but I'd like to keep this somewhat lean. What do you have in
mind? Separate icons for warnings, errors, information screens? That should be
doable, but I don't think I'll get around to do it for this release.
Yeah, that is exactly what I had in mind. No problem.. .
5. Where should the rkh files go for this?
I suggest you create one or two rkh files detailing the graphics device, plot
history, and associated settings. Place this in rkward/pages. You may want to
start linking it to the few existing pages in that directory, where
appropriate. I'll look into adding a direct link to this page(s) in the Help-
menu of the graphics window, later.
OK,
--
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] plot history: 3rd attempt: request for feedback
Hi, I have added a checkbox to enable/disable the history. Settings RKWard Output. It will work in the current session itself. Re-enabling may cause some issues.. -- 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
[rkward-devel] plot history: 3rd attempt: request for feedback
Hi, I've just committed another attempt at the plot history feature(s). Please test it. Some notes follow: 1. Implemented action: 1a. first / prev / next / last 1b. Remove plot 1c. Forcefully append plot, irrespective of its status and type 1d. Clear history 1e. Drop down menu Insert and Overwrite actions haven't been implemented and I do not intend them for this release. 2. par (mfrow/mfcol) and split.screen have been accounted for, almost! 3. Although there is limit on the size of individual plots, one crossing that limit the user is now presented with an option to save or ignore this over-sized plot... This way, such plot are not lost. 4. As usual, play around with the icons / menus and make sure the behavior is _NOT_ harmful and less confusing. Stuff to try out: . open multiple new (empty) devices . add plots using regular plot calls . update plots using title (), grid () etc... . duplicate device (with saved and unsaved plots) . remove plots . browse using the arrow buttons . browse using the drop down menu and make sure that the order / indices are not screwed up . close device (with saved / unsaved / _no_ plot) . perform actions on inactive device and make sure that the state of the device does not change . perform actions on _one_ device and make sure the display on other devices are not changed . exceed the hist limit . reduce the hist limit from Settings RKWard Output to something below the current hist length . plot large sized plots (for ease of use, you may reduce the plot size in settings) . call par (mfrow = ...) or split.screen (...). It is _not perfect_ but see if is satisfactory.. . if you use lattice then mix lattice and standard calls... . for lattice: try out update (trellis.last.object (), ...) calls . try preview devices.. they should not be tracked at all 5. And MOST importantly, find plotting functions which does not get recorded (technically, ones that do not call plot.new or persp or print.trellis). In such cases (even otherwise) try using the Append plot action. 6. By default all debug output is turned off. If you are so inclined to see (esp on error) call: rk.record.plot$.set.rk.rp.debug (TRUE) # FALSE to turn off This will create a whole lot of messages. 7. The label strings for the drop down menu are by default restricted to 50 characters. If you need to change it, call: rk.record.plot$.set.call.lab.len (60) # or 20 ... See how the it fares on different screen sizes. 8. Summary of all the saved plots (not of the devices) can be found by: rk.record.plot$getSavedPlotsSummary () # this is data.frame 9. Summary of the managed devices can be found by: rk.record.plot$getDevSummary () # but this needs debug to be TRUE Of course, there are a lot debug commands, although no output is produced, which will be removed once the performance is acceptable. Regards, -- 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
[rkward-devel] some separate queries related to the plot history feature
@ Thomas: 1. There was some hickup while committing (I hadn't updated in a while). I hope none of your commits are screwed up. 2. Are the message boxes of fixed height but variable width? Some of the multiline text gets eaten up after 5/6 lines. But I guess, one should not narrate stories via message boxes ;) 3. We will need to wrap dev.set and dev.copy.. Otherwise, an independent user call of dev.copy (device = x11, ...) will not amount to the duplicate device behavior... But before doing so, we'll have to be careful to avoid recursion. 4. Is it possible to assign icons to the message boxes? (This is not at all important though) 5. Where should the rkh files go for this? Regards, -- 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] Snapshot 7 sep: new plot window too big
On Wed, Sep 8, 2010 at 7:05 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Tuesday 07 September 2010, Prasenjit Kapat wrote: Just a thought: can we make the toolbar configurable? User's can keep whichever they use most. Um, yes. Settings-Configure Toolbars... Ah, never realized there was a Settings there! Sorry. So it's really just about the defaults. Right. -- 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, 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
Re: [rkward-devel] Programa de orden financiero y manejo inteligente del dinero
sorry, hit accept instead of reject! this is spam. 2010/9/6 rosalinda duran duranrosalind...@gmail.com: Hola, reciba un cordial saludo. El motivo de comunicarme con usted es para invitarlo a un Programa de Ordenamiento Financiero y control inteligente del dinero. No es un curso de contabilidad, lo que se busca es ayudar a corregir los hábitos financieros a través de un ordenamiento financiero personal. A través de este va a poder alcanzar: 1-Desarrollo de un plan para ordenar sus finanzas. 2-Desarrollo de un plan de pago de deudas. 3-Pasos para alcanzar una brecha de ahorro. 4-Diagnóstico y conciencia de su situación financiera actual. 5- Definición de parámetros mentales que definen su comportamiento. 6-Cambio de hábitos para lograr su libertad financiera. 7-Programa de Reacondicionamiento Financiero en 60 Días. Si necesita más información puede ingresar a la siguiente dirección electrónica: http://descubrelibertad.wordpress.com/testimonios Testimonio de un especialista de finanzas que tomó el programa en Perú: http://www.youtube.com/watch?v=LuqxN5W7UDY Quisiera reunirme con usted para explicarle un poco más del programa si está interesado. Por favor contáctese conmigo a la siguiente dirección electrónica: r.lind...@hotamil.com Atentamente Dr. Rosalinda Durán Celular 506-87867578 -- 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 -- 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
[rkward-devel] plot history featrues
Hi, Since I am trying do this from scratch, let me try to chalk out the intended features and expected caveats. So please comment with your suggestion / objections. 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 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 3. multiple plots on the screen: - check for par (mfig) and graphics:::.SSexists (sp.screens) 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? 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) f. clear history g. plot properties 5a. first / prev / next / last - 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 - 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 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 priority, may not work at all [*1] use either identical (a,b) or identical (a[[1]], b[[1]]) [*2] For plots saved via a - recordPlot () a[[1]] is all that is sufficient I think. It contains the data as well as the meta data. In that case, we can hash using digest (a[[1]]) and later (more?) reliably identify / track duplicated plots in the history? (Make digest a dependency of rkward or make it modular?) 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 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
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] altering rk.graph.on and rk.graph.off
Hi, On Wed, Sep 1, 2010 at 12:02 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Saturday 28 August 2010, Prasenjit Kapat wrote: I've modified the rk.graph.on () and rk.graph.off () functions slightly in trunk. Since many might be using these functions (as it is used in a lot of plugins), here is a little explanation: yes, I think this is a good idea, indeed! I wonder whether the set.active.device parameter is actually needed, however. I see you use set.active.device=FALSE, for the copy to output action. But isn't the net effect the same as the default set.active.device=TRUE? The only difference I can see is that the graphics window to be copied is not activated in this case. But then why not? Most other interactions with a graphics window lead to activation, too, and why shouldn't they? Well, in implementing the plot history actions, I've always reset the active device to whatever was before the action was called. My view is this: The user can have one screen device active (for plotting) and can browse the plot history on another screen device. None of the browsing actions should change the active device. But then, Copy to output is not really a browsing action, so yes, we can set it as active. I've cleaned up the code. I was actually in two minds while implementing it. Note that dev.set (non.current.device.number) will open a new device. This could cause confusion in the (unlikely) case that the previous device was closed in between calls to rk.graph.on() and rk.graph.off(). So I'd suggest to re-write the line rk.graph.off() as if ((!is.null (i)) (i %in% dev.list ()) dev.set (i) Yes, this is precisely what I did after replying to Stefan yesterday. 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] altering rk.graph.on and rk.graph.off
On Wed, Sep 1, 2010 at 12:21 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Tuesday 31 August 2010, Stefan Rödiger wrote: Am Dienstag 31 August 2010, 05:54:41 schrieb Prasenjit Kapat: I am guessing it should be easy to do, without the syntax highlighting. Looking at plugin/rkstandardcomponentgui.cpp, just sending code_property-Preprocess () + code_property-calculate () + code_property-printout () to .rk.cat.output () would do it. Of course, a button on the GUI somewhere. go for it ;) The button action will be more appropriate on the plugin dialog box rather than on the screen device window. (All though, I have arguments in favor of device window as well.) why not both (at least for testing)? well, it will be a good deal more difficult to add in the screen device window, since it is hard or even impossible to track which commands were used to create that plot. True, for a preview-window we could get that information from the plugin, somehow, but in fact even a preview window could be modified from the command- line, and we'd have no chance to track the code for those changes. So I don't think that can be done in a reasonable way. 2) This is not really limited to plots. Copying the R code to the output is interesting for any plugin. And in fact this is not really limited to plugins, either. On the users' list, Augustin Lobo asked for an option to carbon-copy R commands from the console/script windows to the output. Therefore it may make sense to implement this at a more central place. E.g. a global option / button to turn transcription of R commands into the output window on / off. We may need to toy with some ideas, here, but in any case I think this is probably something for 0.5.5, rather than 0.5.4. Fair enough. This, if done at the right place, will be a great feature. 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] Vimeo Registration Confirmation
On Wed, Sep 1, 2010 at 8:54 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 30 August 2010, Prasenjit Kapat wrote: Hmm, I am a bit surprise now, but I know the culprit - me! A late night copy-paste error on my part! I pasted the rkward-devel id instead of mine! Ignore it! ok, so I've gone and deleted that vimeo account. Thanks, should've done it myself :( -- 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, 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, 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.
[rkward-devel] anyone using KDE 3 version of rkward?
Hi, I would like to know how many folks still use the KDE3 version of rkward (0.4.9x). The reason I ask is this: I've, partially, ported some of the recent plot history features to it. It is not clean but satisfies my day-to-day needs (Yes, I have to use the KDE3 version in the department!). If there is a demand, we can try to release another version of it: 0.4.9d (?) (If Thomas agrees!) The KDE4 version and its bug fixes will be the top priority, of course. So, the 0.4.9d release, if done, will be at least a few weeks after the upcoming 0.5.x release. I just wanted to get a heads up! For those wondering about the plot history feature, it is a browse-able history of plots that the user creates. A screen shot is here: http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Screenshots#Graphics_history_actions_.28from_trunk.29 The screen shot does not represent the final version, it is subject to change. 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] Vimeo Registration Confirmation
On Mon, Aug 30, 2010 at 3:08 AM, meik michalke meik.micha...@uni-duesseldorf.de wrote: hi, am Montag 30 August 2010 (08:22) schrieb Vimeo: Welcome to Vimeo! what's that about? Hmm, I am a bit surprise now, but I know the culprit - me! A late night copy-paste error on my part! I pasted the rkward-devel id instead of mine! Ignore it! -- 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
[rkward-devel] Request for feedback on plot history
Hi, Following this thread from Thomas: http://www.mail-archive.com/rkward-devel@lists.sourceforge.net/msg00872.html I would like to get some feedbacks, especially bugs. Here is a screenshot of the new screen device window: http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Screenshots#Graphics_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) 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. Some notes: 1. Settings Configure RKWard Output has settings for the history length and size 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. 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.html 4. Remove from history is self explanatory 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!) 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 status bar c. A drop down menu for the history? I plan to have the a. done before the release. The other two can be delayed to a later version. -- Prasenjit [1] The vimeo mail earlier was part of trying to open an a/c for uploading this screen cast. Unfortunately, although I opened it correctly today, they won't accept the resolution! -- 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] altering rk.graph.on and rk.graph.off
Hi, I've modified the rk.graph.on () and rk.graph.off () functions slightly in trunk. Since many might be using these functions (as it is used in a lot of plugins), here is a little explanation: As you may know, in R, after dev.off () closes the current device, dev.next () is set as active. This applies to RKWard as well. But, when rk.graph.on (); ; rk.graph.off (); # dev.off () is called inside rk.graph.off () is executed (in some form or the other), dev.next () is not necessarily the device that was active before rk.graph.on () was called. This creates a little confusion (at least to me, see [1] below) especially when copying a device to output via Device Copy device to output. Hence the fix. For those following the trunk, let me know if you see any regressions or non-intuitive behavior. Of course, this only affects rk.graph.on and rk.graph.off and DOES NOT alter the usual (R's) behavior of dev.off (). Regards, -- Prasenjit [1] x11 () plot (0,0) x11 () plot (1:10,1:10) dev.copy (device = rk.graph.on); rk.graph.off () dev.off (); # closes the wrong device, w/o the fix. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] limiting onscreen graphics history
Hi, On Wed, Jun 30, 2010 at 12:25 PM, Prasenjit Kapat kap...@gmail.com wrote: Hi, On Wed, Jun 30, 2010 at 6:20 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Wednesday 30 June 2010, Prasenjit Kapat wrote: 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. I'm somewhat undecided between 2 and 5. 5 is most elegant, technically, but 2 may be slightly easier usability-wise. I think it depends on what we believe how what would be sensible values for L, s and S. For L, I believe the ~5-10 most recent plots are the most interesting by far, but we could assume 20 to be on the safe side. Regarding s, the object.size() of plot(rnorm(10)) is around 1.6MB, here. So, if we set s to 2MB, that should support pretty much any plot in practice. Multiplying that in solution 2 would yield 40MB. That *is* pretty large. On the other hand, S would _typcially_ be much smaller in solution 2, and on systems where 40MB are a serious issue, RKWard may not be a good choice in the first place. In solution 5, memory-usage would always approach S after extended usage, so it may be reasonable to set S somewhat lower, perhaps at 10MB. How large is a typical plot? My guess is 50KB. That would mean 200 plots can be stored in 10MB for solution 5. For solution 2 that means the typical memory use for the plot history is 1MB. Hm, ok, after writing this down, I think I'm inclined towards solution 2. Thanks for the numbers! If no one has any objection, then I shall implement 2 shortly. I've implemented the limits as discussed above. Two things came up: 1. s = 50 KB seems small even for a pie (...) plot! Which was a surprise, but it validated the code implementation. Let's stick with 50 KB as the default for now. Once this feature is field-tested by others, if needed, we can change it easily. 2. What to do when the max history length (or size) is reduced from the settings, while there is an existing history? What I mean to say is this: suppose L = 10 is set in the settings. Let H = length of the current recorded history. Suppose H = 8. Now suppose the user decides to reduce L to 5 in the settings. So, there are 3 extra plots in the history. Two ways out: 2a. Do nothing (which is the status quo). In this case, there is a warning displayed in R (not in KDE) and no new plot is added the history. 2b. Pop out the first 3 plots, so that H = 5 and then any new plot can be added the usual way (pop the first and push the last) Do you think 2b is a better solution than 2a? Opinions? I (think, I) have all the necessary code in place to implement 2b, so it should be relatively easy. There is a similar situation if 's' is reduced below max (all individual recorded plot sizes). So, popping plots out of history in this case would almost reduce to the case 5 above; which I'm not too comfortable with it. In any case, it would be nice to show a KMessageBox warning (instead of / along with, the warning in R) from KDE in both these situations. This would require R to send the value to H back to C++ whenever the length of history changes - which is already being by updateDeviceHistory. Can it be accessed from the rksettingsmoduleouput? Since updateDeviceHistory has no information on the 'size,' it may be better to create a separate rk.do.call () with history_length and max_existing_size as the two arguments and connect it to rksettingsmoduleoutput. Or may be there is a simpler/better way... Regards, -- Prasenjit PS: @Stefan, I haven gotten around to your JSS email yet. Will do so soon. -- 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
Re: [rkward-devel] paginate onscreen graphics device
Hi, On Mon, Jun 21, 2010 at 8:41 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Opinions, suggestions, criticisms are welcomed. Looks pretty neat, already! Some comments and wishlist: - Keeping one global history seems reasonable to me. - dev.interactive() or deviceIsInteractive() might help in figuring out which devices to ignore. Or perhaps, adding a call to onAddDevice() in rk.screen.device() will allow to keep a list of devices to watch. Note that RKWard preview windows should probably also be ignored (.rk.preview.devices). - Perhaps it would be useful to track the creation time or even the main title of each plot (if you can find a way to do that). Then we could additionally offer a drop-down list of the plots in the history. - internal.R and public.R are really getting crowded. Perhaps you can split all graphics functions into one or more separate files? (svn add to add the new files to SVN). - Some (configurable) way to limit the number/memory size of plots kept in history would be nice. OK, so except one, all of these have been implemented. Taking care of the corner cases is probably the most troublesome. The current implementation should be fairly usable though. I'll keep testing, and add 1. some error checks especially since the wrapper functions are being made public. 2. a wrapper for trellis / grid graphics (Does anyone know what is the analog of plot.new in lattice?) Except one: creation time / main title! I couldn't find a way to get anything out of the return value of recordPlot (). The only thing possible is to replayPlot ()! It is being stored as a raw data. But I think there is a way around (I'll dig into this). More comments are welcome. 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
Re: [rkward-devel] limiting onscreen graphics history
On Mon, Jul 5, 2010 at 1:03 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: How about this (could cover the case of reduced 's', too, if you think it's important enough): When the limit is decreased: 0) Accept the setting, i.e. reduce the limit. 1) Check whether the history will need to be reduced. If so: 2) Notify the user that the history will be trimmed. This *could* include the question, whether to trim the history at once, or to delay that until the next plot is added. In either case the notification will come from R, and be all R code (i.e. do not make the C++ more complex). 2 can be done today using readline(). I always intented to add something like rk.ask.yesnocancel (question=Go for it?, label.yes=NA, label.no=NA, label.cancel=NA) to have a simple generic way to display a messagebox from R code. This will be relatively easy to do, so you can assume it will be done before the release (and nag me about it, if necessary). This feels like a much better way to implement things. I'll do it with readline () and then change it to rk.ask.yesnocancel () whenever possible. 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
Re: [rkward-devel] limiting onscreen graphics history
On Mon, Jul 5, 2010 at 1:15 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Wednesday 30 June 2010, Prasenjit Kapat wrote: I can improve .rk.grapch.history.gui () marginally so that not all the devices need updating when browsing through history. I haven't looked into your code in detail, but I'm afraid, this had side- effects, and I suggest to revert this part to the slightly wasteful, but simpler, and not significantly slower solution from before. Bug reports, for the current implementation: Run plot (1, 1) plot (2, 2) x11 (); plot (3, 3) - The device history should contain at least two items (1,1 and 2,2) at this point. However, the next-button remains disabled for the first device. - Sometimes the previous-button remains enabled when at the start of the history, and in fact, clicking it, I can wrap around to the last plot. Then sometimes it will be disabled at some point, but I have not figured out, when or why. Thanks. I'll look into it. The logic has probably gotten more complicated than necessary! Keep more of them coming... 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
Re: [rkward-devel] updateHistoryActions and rInterface ()-issueCommand
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
Re: [rkward-devel] .GlobalEnv crashing rkward
On Sun, Jul 4, 2010 at 8:27 PM, meik michalke meik.micha...@uni-duesseldorf.de wrote: hi, am Montag 05 Juli 2010 (01:19) schrieb Prasenjit Kapat: If code completion is enabled in Settings Script editor, and you start typing .GlobalEnv, as soon as you reach 'v' it crashes hm, i can't reproduce the crash (Qt 4.6.3, KDE 4.4.5, RKWard 0.5.3), neither on the R console nor in the script editor. Well Qt 4.6.3, KDE 4.4.4, and RKWard 0.5.4-test5 (svn) ... Debian/sid doesn't have 4.4.5 yet, but I guess this may have more to do with the svn code than KDE. Lets see if anyone else can reproduce this -- 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
Re: [rkward-devel] paginate onscreen graphics device
Hi, On Tue, Jun 29, 2010 at 2:58 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 28 June 2010, Prasenjit Kapat wrote: I haven't tested the new code yet, but is there a 'catch-22' issue here? The dev.off () bug was solved by forcefully closing / killing the window and now the closing itself is mapped to dev.off ()? well, there is a lot of indirection, but not a full circle, of course. Basically the steps are: 1) Clicking the close-button (or Window-Close) keeps the window alive, but calls dev.off(). This is mandatory, otherwise we wouldn't have a chance to record the unsaved plot. 2) dev.off(), before calling the internal dev.off(), tells RKWard to close the window. 3) At this point the window is closed immediately in the GUI thread. OK, that makes sense now. I see. So I'll just turn this into a bug-report, let you deal with it: Create a few plots to have a plot history. Close all devices. Open a new device. The device is now at the start of the history (Next plot is active), not at the end (Prev plot is not active). Ah, missed that one totally. Fixed in svn, thanks. -- 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
[rkward-devel] paginate onscreen graphics: cpu 100% when browsing through history
Hi, I've been seeing this for a few days now. As soon as First / Prev / Next / Last arrows are clicked on the device toolbar, cpu (one core) jumps to 100% and the core temperature shoots up. I haven't been able to figure out the reason. The R part seems straight forward to me. Any idea? 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
Re: [rkward-devel] paginate onscreen graphics device
Hi, A quick question: On Mon, Jun 28, 2010 at 11:01 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: - In dev.off(): I believe my suggestion to use dev.interactive() was not a good idea, after all. dev.off() allows to specify a device number which is not currently active, but dev.interactive only returns info on the active device. Alternative suggestion: If a known current index exists, then obviously this device was managed in the history. If the index is NA/NULL, then it was probably unrelated. I.e. always call onDelDevice from dev.off(), but make onDelDevice smarter. Does the RKWindowCatcher::killDevice (int device_number) function in rkwindowcatcher.cpp (line 82) work for non-interactive devices as well, in the sense that nothing is done? My guess is Yes, because 'window' should be null / 0 / false, right? -- 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
Re: [rkward-devel] paginate onscreen graphics device
Hi, On Mon, Jun 28, 2010 at 11:01 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 21 June 2010, Prasenjit Kapat wrote: Basically, something along the following lines: RKGlobals::rInterface ()-issueCommand (rk.record.plot$onDelDevice ( + QString::number (device_number) + ')', RCommand::App, i18n (Add current plot before closing device number %1, device_number), error_dialog); what I have done now, is to simply call dev.off() when the user tries to close the device using Window-Close or the close-button. That way, we have only a single place where onDelDevice() is called from, which is always a good idea. I haven't tested the new code yet, but is there a 'catch-22' issue here? The dev.off () bug was solved by forcefully closing / killing the window and now the closing itself is mapped to dev.off ()? 2a. A better solution would be provide a toolbar for the graphics window. Then have them under View and add them to the toolbar as well. The toolbar, in far enough future, could be used to add more editing features! As you can see, I've added a toolbar, although I guess the First plot, Last plot, and Clear History actions should not go into the toolbar by default, in the final version. Suggestions on better icons are always welcome, at this and all other places. Yes, I saw the toolbar. It is way more appealing now. I am fine with the current icons. These are cosmetic issues. Opinions, suggestions, criticisms are welcomed. A few more things: Always helpful. I have few other things in the process. I'll take it up on a separate thread later. - On line 75 of public_graphics.R, I think it should be current [[deviceId]] - length (recorded)+1L (if the previous device *was* the null device, the new window should still be at the end of the current history). I don't really understand the newPlotExists-list. No idea, whether or not the same problem applies, there. If you mean this line: current [[deviceId]] - current [[duplicateId]] then, the 'duplicateId' is needed because: when Device Duplicate is called, I want to keep the the new window at the same history position as the old window. Moreover, the length increment happens only when a valid record () call is made; not necessarily when a device is added. Or may be I am missing your point. newPlotExists just tracks whether or not there is any _new_ plot on a device which hasn't yet been added to the history. It relates to the fact that when record () is called from plot.new () the _previous_ (which is now assumed to be complete) plot gets recorded and not the current (possibly incomplete) one. - In dev.off(): I believe my suggestion to use dev.interactive() was not a good idea, after all. dev.off() allows to specify a device number which is not currently active, but dev.interactive only returns info on the active device. Alternative suggestion: If a known current index exists, then obviously this device was managed in the history. If the index is NA/NULL, then it was probably unrelated. I.e. always call onDelDevice from dev.off(), but make onDelDevice smarter. I was delineating between two concepts: (1) rk.record.plot () and anything inside it deals only with storing/deleting/replaying plots and in that sense is called only for interactive non-preview devices and (2) the onus of calling record / onAddDevice / onDelDevice rests on the calling function. But now I think, this is not a wise way to delineate stuff. Going by your way, I will want to make onAddDevice () and record () smarter as well; taking the respective burdens off rk.screen.device () and plot.new (). Just to be consistent, if possible. I'll dig into this. - Perhaps some code could be made easier by casting the device numbers to string using as.character(). Then the device numbers could be used as real names in the list, instead of indexing. But this concerns aesthetics, only, and may not be worth the trouble. This is a much better idea. It should take care of the situation when device n+1 is an open-interactive-non-preview device, but device n is either non-existent on a non-interactive or a preview device. - Once the details of your code are sufficiently stable, it would be good, if you could add one or more tests to rkward_application_tests.R. Naturally, not all things can be tested from there, but you could add some checks, whether all indices are correct after adding/removing devices, etc. Let me bring the code to a more stable and acceptable state first! -- 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
Re: [rkward-devel] dev.off () bug
Hi, When you find some time, here is some more information: this bug seems to be related to KDE 4.4.x series; see below. On Mon, Jun 21, 2010 at 4:17 PM, Prasenjit Kapat kap...@gmail.com wrote: On Mon, Jun 21, 2010 at 12:09 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Monday 21 June 2010, Prasenjit Kapat wrote: Calling dev.off() creates a new cairo device instead of closing the existing one: plot (1,1) dev.off() I don't see this, here. Do you get this every time or only sometimes? Everytime. Case 1: Kubuntu 9.10 in a virtualbox; compiled rkward trunk against R 2.9.2 as well as 2.11.1 (from cran). In both cases dev.off () worked fine. Note here that Kubuntu 9.10 has KDE 4.3.2 Case 2: Debian/Sid moved to KDE 4.4.3 very recently; so even near the end of April / beginning of May my system had KDE 4.3.y and I hadn't noticed this bug Case 3: Kubuntu 10.04 in a virtualbox; ran stock rkward-0.5.2 against stock R 2.10.2. KDE is 4.4.2 and the bug shows its ugly head ;) On Mon, Jun 21, 2010 at 6:24 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Monday 21 June 2010, Prasenjit Kapat wrote: I do have a wrapper around dev.off: testable as soon as the bug is taken care of. Ok, then here's an idea for a hack around the bug: Directly before the real dev.off() add .rk.lock.device - TRUE and .rk.lock.device - FALSE directly after. In rk.screen.device add if (exists (.rk.lock.device) .rk.lock.device) return at the start. Well, this didn't help :( Issue persists. Let me know if you need any more info (when you find time). Regards -- Prasenjit -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] paginate onscreen graphics device
Hi, On Mon, Jun 21, 2010 at 12:41 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Monday 21 June 2010, Prasenjit Kapat wrote: RKGlobals::rInterface ()-issueCommand (rk.record.plot$onDelDevice ( + QString::number (device_number) + ')', RCommand::App, i18n (Add current plot before closing device number %1, device_number), error_dialog); Ok, will do this. But it may take a few days. dev.off() (which is also called by graphics.off()) will have to be handled in R. I do have a wrapper around dev.off: testable as soon as the bug is taken care of. 1. The disable parts haven't been implemented yet. Right now, once you reach either end nothing is replayed. Can you arrange for some function to be called whenever the history-length or position changes? Then I can take care of updating the state of the menu items. Sure, let me know what you want the function to do? Opinions, suggestions, criticisms are welcomed. Looks pretty neat, already! Some comments and wishlist: - Keeping one global history seems reasonable to me. - dev.interactive() or deviceIsInteractive() might help in figuring out which devices to ignore. Or perhaps, adding a call to onAddDevice() in rk.screen.device() will allow to keep a list of devices to watch. Note that RKWard preview windows should probably also be ignored (.rk.preview.devices). - Perhaps it would be useful to track the creation time or even the main title of each plot (if you can find a way to do that). Then we could additionally offer a drop-down list of the plots in the history. - internal.R and public.R are really getting crowded. Perhaps you can split all graphics functions into one or more separate files? (svn add to add the new files to SVN). - Some (configurable) way to limit the number/memory size of plots kept in history would be nice. Great. I'll look into these in the next few days. Regards, -- Prasenjit -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] paginate onscreen graphics device
On Sun, Jun 20, 2010 at 9:22 AM, Thomas Friedrichsmeier
thomas.friedrichsme...@ruhr-uni-bochum.de wrote:
Hi,
On Saturday 19 June 2010, Prasenjit Kapat wrote:
Looking at Deepayan's reply:
http://article.gmane.org/gmane.comp.lang.r.debian/1268
i think it might be easy to implement the history part (paginated
device may be more difficult) for our graphics device.
The idea would be to store the plotting calls into a list
(.rk.something) and with two top level menu entries ('' and '') on
the graphics window we could flip through the list...
Is it at all easy to implement, or am I hallucinating?
first a technical note: The graphics device in RKWard is simply the native R
device. All we do is to capture that window, and add our own menus to it.
Thus, the difficult part remaining from Deepayan's mail is 1: figuring out
just
when R is about to overwrite the existing plot with something new
(alternatively: figuring out, when a plot has been completed). Unfortunately,
the hook in plot.new() gets called directly *after* the previous plot has been
blanked, so that is too late for our purpose.
OK. I see the problem now. I have two questions: Is it possible for
rkward to know
1. when/if the current device is altered? For example, suppose abline
() is called after a plot() call, does rkward know the device has been
modified? My guess is No.
2. when/if the graphics window is closed? I can handle dev.off () and
graphics.off() but what happens if the close button on the window is
clicked? Or Window Close (Ctl+W) is clicked? Do rlward still have a
chance to do _something_ (I've an idea of what to do) with existing
graphics?
I suppose it might be possible to override plot.new() using
assignInNamespace(). See the bottom of internal.R for our procedure to
override menu and select.list in the utils package (rk.fix.assignments()
is called during initialization).
Nice!! I've done exactly that and have a rudimentary code based on
Deepayan's rp () which is working! But yet to commit to svn. I've to
figure out where/what to add/modify in the C++ codes to add additional
GUI elements to the menu of the graphics window. May be you can help
here.
(Of course there are some additional questions to find an answer for, such as:
Keep a separate list for each device window, or a single list for all? Clear
the list, when the corresponding device windows is closed?)
Yes, there are a lot of questions... We'll need to separate out (that
is not record) the devices which are not on-screen, such as pdf, png,
etc... But let me start with a global list and see where it goes... If
it is too flaky then we may scrap the idea completely.
Regards,
--
Prasenjit
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel
[rkward-devel] dev.off () bug
Calling dev.off() creates a new cairo device instead of closing the existing one: plot (1,1) dev.off() Warning message: In dev.off() : Display list redraw incomplete X11cairo 4 Now, calling dev.off() twice closes the two devices. dev.off() X11cairo 3 dev.off() null device 1 This doesn't happen if x11() is called explicitly: x11 () plot(1,1) dev.off() null device 1 x11(type='Xlib') or x11 (type='cairo') or x11(type='nbcairo') behave fine as well (ie when called explicitly before plotting). Other devices: pdf () or png () (and hopefully others) work fine too. Reagrds, -- Prasenjit PS: This is independent of my graphics history modifications... But I am working with the current svn. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] On windows binary
On Fri, May 21, 2010 at 9:46 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Thursday 20 May 2010, Prasenjit Kapat wrote: I don't see any difference by adding %~dsp0 to R_BINARY on Windows 7 as well as Win server 2007. Once RKWard starts the getwd() is still C:/.../KDE/bin. you need to do both: Modifiy rkward.bat, and specify %USERPROFILE% as working directory in RKWard.lnk. Ah, I had missed that earlier... Now (w/o the setwd() line in .First.lib()), this works as expected. -- Prasenjit -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] On windows binary
Hi Thomas, On Tue, May 18, 2010 at 10:36 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, a small update: Thomas Friedrichsmeier schrieb: I guess the most elegant way may be to set the working directory in the RKWard.lnk . I believe it's possible to use path-variables such as %USERPROFILE%, there, but again, well have to test this. I tested this on Windows XP, and it works, there. I had to adjust rkward.bat for this to work, though: SET R_BINARY=%~dsp0\..\..\R\bin\R.exe %~dsp0 means drive letter and short path of current script. Since the working directory is no longer KDE\bin, using the pure relative path would fail. @Prasenjit, could you give this a short test esp. on Windows 7 (where some of the default paths have chnaged)? I don't see any difference by adding %~dsp0 to R_BINARY on Windows 7 as well as Win server 2007. Once RKWard starts the getwd() is still C:/.../KDE/bin. -- Prasenjit -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] On windows binary
On Sun, May 16, 2010 at 6:38 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Sunday 16 May 2010, Prasenjit Kapat wrote: 1. An option for a Home directory on Windows would be preferable, defaulting to %USERPROFILE%. Otherwise rkward starts in \KDE\bin, which for obvious reason is not good! The could be achieved as: if (grepl (pattern = RKWard/KDE/bin$, x = getwd())) setwd (Sys.getenv (Home)) somewhere part of the startup? Well, what if we could add the following to .First.lib () for rkward, as an interim solution? if (.Platform$OS.type == windows) setwd (Sys.getenv (HOME)) Sys.getenv () will work on any windows variant... And, I checked, it works on XP, Windows 7, and Windows Server 2007 with native R (no KDE). So, I think this is doable. Currently I've added that line manually to the end of .First.lib () in RKWard/R/library/rkward/R/rkward If I add the following to Rprofile.site: .First - function () if (.Platform$OS.type == windows) setwd (Sys.getenv (HOME)) Then, Rterm.exe honors it but RKWard does not. 3. Is PHP still a requirement on Windows? No (unless you still have some self-made PHP-based plugins; all official plugins use JS, now). Is it still being mentioned at some places? I see, so the PHP Backend option in settings is just a safe-guard. -- Prasenjit -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
[rkward-devel] On windows binary
So, here are the points: 1. An option for a Home directory on Windows would be preferable, defaulting to %USERPROFILE%. Otherwise rkward starts in \KDE\bin, which for obvious reason is not good! The could be achieved as: if (grepl (pattern = RKWard/KDE/bin$, x = getwd())) setwd (Sys.getenv (Home)) somewhere part of the startup? OR, as arguments to the batch file? (I have no idea of DOS scripting ;)) 2. This concerns KDE, so not much we can do: The first instantiation of RKWard, on Win 7, asks for admin access to run update-mime-database.exe and kconf_update.exe. Answering No works, no apparent harms, yet. 3. Is PHP still a requirement on Windows? 4. As mentioned in an earlier thread: Some KDE process keep running after rkward is closed: dbus-daemon.exe, kioslave.exe, klauncher.exe. kded4.exe, kio_http_cache*, . Will it be a good idea to kill them (or provide an option to do so) while exiting from RKWard? I've created the following script: KDE_Cleanup.bat: @ECHO off taskkill /F /IM kio_http_cache* taskkill /F /IM klauncher.exe taskkill /F /IM dbus-daemon.exe taskkill /F /IM kded4.exe Could this be automatically run after rkward? It may not be the right thing to do ;) But we could provide this as part of the whole package. Regards, -- Prasenjit -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] static windows binary
On Wed, May 5, 2010 at 5:32 PM, meik michalke meik.micha...@uni-duesseldorf.de wrote: now that i've toyed around with the windows version a little (nice to see that rkward can be run from a network share and even a DVD without installation), i was wondering if a static build was possible. This is a really interesting idea and I believe it will be really helpful in making a non linux person try rkward. well, i'm not using windows anyways, but it's hard to convice someone to give rkward a try if that means to install so much otherwise unneeded stuff. apart from that, of KDE could be stripped down to the really needed parts, rkward could easily be burnt as a live CD for windows users. how do you feel about this? I had installed a 0.5.3-preX version on a Win 7 tablet a few days back. And IIRC: * KDE installed fine, did not need any admin rights (UAC or whatever they call it) * but RKward needed an admin password to install! I am just thinking out loud now: For windows split rkward into three parts: 1. Core rkward which will have a special config file. The config file will provide the path to KDE, R folders. I think this is already in place. 2. Provide a zipped archive of essential KDE libraries and stick with this till the next releasable version of rkward. These KDE libs should be from the most stable version of KDE on windows (need not be latest). 3. Provide the latest R binary (preferably in a zipped form, not as an installer). (Of course, 2, 3 above should be optional; in the sense that, if the user already has an existing KDE and/or R installation then allow him/her to use those instead.) So that the following steps could yield a usable Rkward on windows: 1. Create three folders C:\Rkward\rkward, C:\Rkward\KDE, C:\Rkward\R (just example) 2. Unzip the bundled KDE libs into C:\Rkward\KDE 3. Unzip the bundled R into C:\Rkward\R 4. Unzip rkward into C:\Rkward\rkward, 5. Open the special config file and specify/modify the KDE and R paths 6. Create a shortcut to C:\Rkward\rkward\rkward.bat (or whatever is the correct executable binary is windows) on the desktop Now again, these are just wild thoughts... -- Prasenjit -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Second call for testing: RKWard 0.5.3-pre2
Hi On Fri, Apr 23, 2010 at 7:29 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: to give it a try). Anyway, the page exists at http://launchpad.net/rkward, and perhaps it may still be interesting to keep for other features (such as PPAs). Ah, I had created a launchpad page a long time back for this purpose (while I was high on ubuntu!) but could figure out their package upload procedure They kept on rejecting my uploads :( And then I gave up debugging... Anyway this is really a welcome move and may add some official flavor to the (unofficial) ubuntu builds ;) -- Prasenjit -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] [rkward-users] Call for testing: RKWard 0.5.3-pre1 / Release schedule
HI, On Wed, Apr 21, 2010 at 1:20 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Wednesday 21 April 2010, Prasenjit Kapat wrote: BTW, is kate's 'Filesystem Browser' different then? This doesn't seem to happen there. (Its 'tab bar' is completely different, a bit weired, if I may.) Good point. The solution is that kate simply refuses to open the same file twice (and in RKWard we were trying to do the same, but there was a bug in that). So that hides the bug in kdelibs, and of course we can do the same thing (that simply did had not occurred to me, when I wrote this was hard to work around). The work around works! Much saner now ;) Indeed. I see the problem, but don't know how to fix this, yet (other than to assign different shortcuts). BTW, the katepart is not to blame. It's the tab- bar that assigns shortcuts to the tabs, apparently without taking existing shortcuts into account. Hmm.. well... at least now the shortcuts are configurable. Ok, I found a way to work around that (and I submitted a patch to kdelibs), so this will not be an issue in the release. I am sure the KDE folks appreciate this. Someday someone may ask why the two different (Alt Ctrl) window cycles? We'll have to come up with some answer, till then Well, by then, I hope to have implemented an Alt+Tab-like window cycling. Once we have that, at least the Alt-type cycle should be pretty much obsolete (and possibly the Ctrl-type cycle as well). Sounds like a good plan. Regards, -- Prasenjit -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] One more preview release: RKWard 0.5.3-pre3
On Wed, Apr 21, 2010 at 1:31 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi again, this is just a quick note to let you know, that a third (hopefully final) preview release is available for download, now. If you can find the time to do some (more) testing, please use 0.5.3-pre3. As usual, a windows binary installer will follow, but probably not before tomorrow. Few other things: 1. Any one have the insanely wide window problem. For example, Configure repositories Fetch list Cancel: the resulting message window is at least three or four screens wide. I'll try to do some more testing tonight and update. 2. (Windows specific, so we may defer it for later. [*]) Some of the save dialogs: for example: Devices Export file open icon, or File Export Save R Objects file open icon If I am giving a new filename, and click the Open button, the dialog says 'File not found' ;) [*] Side note: Got hold of a X200 tablet (w/ win7) for the class I am teaching. I was planning to show some distribution behaviors but at every other thing rkward would get stuck, so I decided to use my Debian laptop in the end. -- Prasenjit -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] [rkward-users] Call for testing: RKWard 0.5.3-pre1 / Release schedule
Hi, On Sun, Apr 18, 2010 at 3:14 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: On Saturday 17 April 2010, Prasenjit Kapat wrote: 1. File browser (Alt+1) 1a. Single click and double click: shouldn't it honor the default KDE settings? Double clicking on a filename opens the files thrice (when KDE default=single click) or twice (when KDE default=double click), neither of which is correct. Indeed. It's a bug in kdelibs, though, and it would be very hard to work around this. Does anybody have a KDElibs 4.4.x installation at hand? Could you check, whether the double-click behaviour is still the same, there? Well, 4.4 is not in Debian yet :( I may give Kubuntu in a VM a try sometime, but I don't think I'll be able to do that in time for the release. BTW, is kate's 'Filesystem Browser' different then? This doesn't seem to happen there. (Its 'tab bar' is completely different, a bit weired, if I may.) 1b. Can we save the view mode (Short view / Detailed view)? The short view seems almost unusable with large number of files and/or large filenames. Implemented in SVN. Please test (another preview release will also follow some time next week). (I miss the List view from KDE3!) (1b can be targeted after 0.5.3) Added an icon for tree view (which is pretty similar, IIRC). Thanks. This looks and works great now, very much usable. The 'icon view' is gone now? (I won't miss it!) 2. Shortcuts 2a. (Although this is specific to my setup, but can occur to others as well.) Some of my codes are named blah.0.blahblah.r, blah.1.blahblah.r, . As a reproducible case, create two (or 6) script files: a0.R, a1.R (..,.a6.R) and open them. Now, Alt+0, Alt+1 ( ..., Alt+6) become ambiguous ;) If this is tied to katepart, then at least having an option to disable script tab shortcuts will be useful! (For some reason this does not happen on KDE3's katepart) Sometime, at this stage, a crash may occur - I haven't been able to deterministically reproduce a crash. Indeed. I see the problem, but don't know how to fix this, yet (other than to assign different shortcuts). BTW, the katepart is not to blame. It's the tab- bar that assigns shortcuts to the tabs, apparently without taking existing shortcuts into account. Hmm.. well... at least now the shortcuts are configurable. 2b. In the absence of Previous (or Next) Window, hitting Alt+ (or Alt+) inputs , (or .) character into the script - which is obviously dangerous. Ideally, the key combination should be disabled in such situations. I can see the problem, but don't know what to do about this, either. I suppose the problem could be side-stepped, if previous would wrap around to the most recent, and next to the first window, so that there is always something reaction to the shortcut. How does that sound? It may get a bit confusing, but far better than messing up the code! It is one thing to see this happening in a blank script file and whole another thing when it happens is a big R code and you save it w/o realizing what was modified... A wild goose chase, when the code doesn't run the next day! So, yeah fine by me. Someday someone may ask why the two different (Alt Ctrl) window cycles? We'll have to come up with some answer, till then 2c. Window Left and Right are always disabled for some reason! Indeed. Will investigate. Looks fixed now, thanks. 2d. Run all shortcut: Has anyone done the mistake of hitting Shift+F9 instead of Shift+F8 (F9 and F8 are close enough)? My suggestion would be to not have any default shortcut for Run all and let the user set one, if he/she needs. Hm, I use Run all a lot, personally, and that makes me reluctant to remove the shortcut. What does everybody else think / use? Again, not a problem at all... I can disable the 'Run all' shortcut easily, so fine by me! 3. make plugintests 3a. Existence of R2HTML should be checked before starting any tests. Otherwise it is really not any useful - all tests are skipped! You have a point, there... 3b. The default size of output buffers (Command log / R Console) are too small for plugintests' output. Can we call sink(file = ...) before and after running the tests? (Or will every plugin need to be modified for this?) Should be possible, somehow. BTW, the tests are just a bunch of R scripts (make plugintests basically sources rkward/tests/all_plugins.R; see also http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Automated_Plugin_Testing), so maybe you would like to take a look, yourself? Updated all_plugins.R using sink(). Do check it for any obvious errors. On another note: I meant to write about this, earlier, but forgot: I modified your solution for the CRAN mirror settings, as discussed some months ago. This removes the hard-coded list of mirrors, but also replaces the tcl-dialog with an rkward native dialog. What do you think of the current state? Yes, I remember the commits in svn
Re: [rkward-devel] Second call for testing: RKWard 0.5.3-pre2
On Tue, Apr 20, 2010 at 5:40 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Thanks everybody for your feedback, so far. I have just uploaded a second preview release (http://p.sf.net/rkward/download - a windows binary will follow in a few hours) which addresses a number of the issues you reported. If you have any time for further testing, please download and try the pre-2 version. Just a quick note: -pre2 isn't available on sf yet. I didn't get a chance to check out from SVN. But will do so tonight. -- Prasenjit -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] [rkward-users] Call for testing: RKWard 0.5.3-pre1 / Release schedule
I'll restrict to the -devel list. Firstly, a big Thanks to Thomas for keeping the project alive and continuing the development. I've recently set things up and have a running rkward 0.5.x on KDE 4.3.4 (Debian sid). But I do not get much time/chance to use it :( (Stuck in office with RedHat!). So here is my few initial comments on the 0.5.3-pre1 version from a brief usage: 1. File browser (Alt+1) 1a. Single click and double click: shouldn't it honor the default KDE settings? Double clicking on a filename opens the files thrice (when KDE default=single click) or twice (when KDE default=double click), neither of which is correct. 1b. Can we save the view mode (Short view / Detailed view)? The short view seems almost unusable with large number of files and/or large filenames. (I miss the List view from KDE3!) (1b can be targeted after 0.5.3) 2. Shortcuts 2a. (Although this is specific to my setup, but can occur to others as well.) Some of my codes are named blah.0.blahblah.r, blah.1.blahblah.r, . As a reproducible case, create two (or 6) script files: a0.R, a1.R (..,.a6.R) and open them. Now, Alt+0, Alt+1 ( ..., Alt+6) become ambiguous ;) If this is tied to katepart, then at least having an option to disable script tab shortcuts will be useful! (For some reason this does not happen on KDE3's katepart) Sometime, at this stage, a crash may occur - I haven't been able to deterministically reproduce a crash. 2b. In the absence of Previous (or Next) Window, hitting Alt+ (or Alt+) inputs , (or .) character into the script - which is obviously dangerous. Ideally, the key combination should be disabled in such situations. 2c. Window Left and Right are always disabled for some reason! 2d. Run all shortcut: Has anyone done the mistake of hitting Shift+F9 instead of Shift+F8 (F9 and F8 are close enough)? My suggestion would be to not have any default shortcut for Run all and let the user set one, if he/she needs. 3. make plugintests 3a. Existence of R2HTML should be checked before starting any tests. Otherwise it is really not any useful - all tests are skipped! 3b. The default size of output buffers (Command log / R Console) are too small for plugintests' output. Can we call sink(file = ...) before and after running the tests? (Or will every plugin need to be modified for this?) 3c. Anyway, ignoring the --skipped-- tests, here are the FAILed ones: shapiro_wilk_test match MISMATCH match (empty) no FAIL ad_test match MISMATCH match (empty) no FAIL import_spss match MISMATCH MISMATCH ERROR FAIL import_stata match MISMATCH MISMATCH ERROR FAIL linear_regression match MISMATCH match (empty) no FAIL shapiro_wilk_test match MISMATCH match (empty) no FAIL ad_test match MISMATCH match (empty) no FAIL As Mat asked, what other FAIL output would be useful? Regards, -- Prasenjit -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Preview release of RKWard 0.4.9c for KDE 3
On Sat, Mar 6, 2010 at 8:56 AM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi! For those who are still using KDE 3 based systems: Please download and test rkward-0.4.9c-pre1 (http://p.sf.net/rkward/download). This finally brings support for the dynamic help system in R 2.10.x, and has a number of further fixes backported from the main development line. -- Release Schedule -- I am unsure, how many of you still have an active interest in these compatibility releases, therefore I do not propose any specific timeline. If you are going to participate testing, please let me know, how much time you will need. I'd like to get this off my TODO list, soon, but of course it should get a decent amount of testing (esp. since this will hopefully be the last KDE 3 compatibilty release we need). As long as R folks don't do anything drastic (like the current help system) I think this should be the last KDE3 related release. Otherwise, depending on when RedHat 6 is released (may be later this yr) and on what it is based on (may be Fedora 11/12 -- hopefully KDE 4.3), we may need one more :( -- Things to look out for in testing -- - Most importanty, of course, please give the help system (help browsing, following links, help search) a decent round of testing. R: 2.10.1 In the past two days, the new help system has been working fine. I'll keep the devel list updated if I see any errors. - If could test with different versions of R (if possible, including prereleases of R 2.11.x), that would be really helpful. R: 2.11 (unstable) Even with a slightly broken installation of 2.11 [*], rkward is doing fine with the new help system. Now, I won't be able to spend much time w/ the pre-release version of 2.11, so testing will be minimal. But if needed, I have a working setup, so I can quickly run some tests. BTW, once rkward is installed (in ~/.kde) is it possible to check which R version it was compiled against, without starting an instance of rkward? Sys.getenv(R_VERSION) works but I have to start rkward first! Once again, a BIG thanks to Thomas. -- Prasenjit * The test installation of R 2.11 is not perfect (it does not seem to add ~/R/.../2.11 to the .libPaths() on startup). But setting the R_LIBS env variable before calling rkward seems to remedy the situation. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
