I have to deploy R+Tinn-R+MySQL for me and some colleagues but I have not
found ideal solutions.
A a matter of fact,
with Tinn-R 1.19.47 and R 2.12.1, Tinn-R doesn't save the RGui path (it looks for RGui in /bin/RGui.exe instead of /bin/i368/RGui.exe). Is there a solution to avoid giving the right place each time ? Where is this information stored so that I change it directly in the file ?
with the last version of Tinn-R and R 2.12.1, Tinn-R finds R without problem but each time I send some lines, I get the following message: source(.trPaths, echo=TRUE, max.deparse.length=150). The script works but it will be nice to avoid this message. Is there a way to fix it ?
Any solution will help be to choose the nicer R/Tinne-R couple.
Thanks in advance for your help,
I found a Tinn.ini file with a sPathRGui=C:\R2121\bin\Rgui.exe entry.
I put C:\R2121\bin\i386\Rgui.exe instead but as I start Tinn-R, Tinn-R
modifies it with the previous (and wrong) entry.
Is there a way to avoid this behaviour ?
Or any advice to use the (R 2.12.1, Tinn-R 188.8.131.52) couple ?
Again thank you in advance for your help.
First of all, check whether You have "Use latest installed version" on "No"
(in Tools, Application options, R, paths). If it is on "yes", then it will
find the latest updated version every time, which is set as the main R
directory. Tinn-R gets that from the PATH variable, which explains why it
always goes back to the initial installation of R. That is the directory you
find in your .ini file.
Second, remember R is installed as from 2.12 as a 32bit and a 64bit
installation together. Tinn-R is adjusted for this, and in the same place
(Tools > Application > R > Path) you can choose which architecture you use.
Simply select i386 architecture and the path is set correctly.
Hope this helps. I have no trouble whatsoever switching back and forth between
32bit and 64bit with that same combination.
Regarding your first question : If you can convince the R-GUI not to print the
commands received, than you can avoid that line. But the problem is not
Tinn-R, it is R itself. The reason for this is simply that Tinn-R uses the
clipboard as a temporary buffer for the commands, and then sends the command
to read that buffer to R. This is the source command you see there.
Your question is equivalent to ask how to prevent R from showing the source()
command if you type it in at the prompt.
When I said "I put C:\R2121\bin\i386\Rgui.exe instead but as I start Tinn-R,
Tinn-R modifies it with the previous (and wrong) entry.", it was with Tinn-R
184.108.40.206 (I have no such a problem with the latest Tinn-R version but I have
And in this older version, I haven't found "Use latest installed version" on
"No" (in Tools, Application options, R, paths) you mentionned.
Do you have another solution to keep the right RGui path with Tinn-R 220.127.116.11
Concerning the source(.trPaths, echo=TRUE, max.deparse.length=150) message,
before you pointed it out, I even haven't thought that the problem was coming
from R (shame on me). I will check this point.
Again thank you for your help,
simple solution : don't use that old Tinn-R version. There's a reason why it
is updated. I can't think of any reason why one would want to use that old
version, as there is nothing that would be no longer compatible with the
current version. The current version is definitely improved on the options,
adjusted for the latest version of R and a whole lot more stable, especially
on 64bit architecture (older Tinn-R versions really act up on my comp).
I have just have to avoid the annoying message (but now I'm convinced that it
comes from R).
If I find the solution, I will add it to this post (but I'm only an end-user
Have a nice end of day.
Err, chances are small you'll find a solution. Maybe I didn't make it clear
enough: Tinn-R uses Tcl/Tk to send the commands to R. It's the equivalent of
you typing that command into R. So that means there is no way in the world you
can get rid of that. It's the equivalence of asking R to not show what you're
typing at the prompt.
One guy thinks that the problem comes from Tinn-R
And reading this post, I observed the same bad behaviour, that is there is no
possibility to re-call the selected commands.
And it was not the case with the lasr R version and the older Tinn-R version.
So I'm no more so much convinced that it comes from R (but I am very
impressionable as you maybe noticed).
Any comments to the link ?
Thanks fr your patience !
Just to say that using Rterm instead of Rgui, I still have the message
source(.trPaths, echo=TRUE, max.deparse.length=150) but with alt+down/+up
combinations, I can re-call the commands (it doesn't stop at the first lines,
it loops but it is already quite ok).
Now I have to unterstand the difference between Rgui and Rterm. Maybe it is
equivalent for my use (I saw a post on this subject, I will read it
If you have some explainations about the differences of communication between
Tinn-R and Rterm and Rgui, I am interested in.
In advance, have a nice week-end,
Copy of the post "Rgui vs Rterm" in the open discussion forum :
Changing the 'InstallPath' in the
HKEY_LOCAL_MACHINE/SOFTWARE/R-core/R32/2.12.1 entry of the register, Tinn-R is
now able to keep the path in the .ini file and then is able to directly
connect to Rgui (I don't know why it didn't work yesterday).
So now my Tinn-R 18.104.22.168 + Rgui 2.12.1 configuration is running well (it
matches my expectations at least).
Maybe it can help other people ...
I posted a question on Saturday 15 Jan 2011 regarding this problem and it is
still vexing me. I am running the latest version of Tinn-R (22.214.171.124) and R
(2.12.1). I am running the packages on a 32 bit Windows XP machine and a 64
bit Windows Vista machine. Before these versions I ran R 2.12.0 and Tinn-R
126.96.36.199 without any trouble. When I attempt to send several lines to R-term I
get the following error: source(.trPaths, echo=TRUE, max.deparse.length=150).
This is supplemented by the following information in the log file:
In getDependencies(pkgs, dependencies, available, lib) :
package 'svIO' is not available
Error in loadNamespace(i, c(lib.loc, .libPaths())) :
there is no package called 'XML'
Error: package/namespace load failed for 'svIDE'
Error in source(.trPaths, echo = TRUE, max.deparse.length = 150) :
object '.trPaths' not found
I know that my Rprofile.site file is set up correctly on both machines, but I
get the same error on both. What is causing this? If I manually enter the
following code into the Tinn-R editor and run it:
.trPaths <- paste(paste(Sys.getenv('APPDATA'), '\Tinn-R\tmp\', sep=''),
c('', 'search.txt', 'objects.txt', 'file.r', 'selection.r', 'block.r',
I no longer get the error but I did not have to do this with previous Tinn-R
and R combinations. I made sure the Rprofile.site file contained these lines
and the trDDEInstall() precursor and all seemed to work well.
Any advice would be greatly appreciated.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.