R2.12.1 and various TINN-R: no ideal solution

  • Ptit_Bleu

    Ptit_Bleu - 2011-01-06


    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,
    Ptit Bleu.

  • Ptit_Bleu

    Ptit_Bleu - 2011-01-06

    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 couple ?

    Again thank you in advance for your help.
    Ptit Bleu

  • JFAM

    JFAM - 2011-01-06

    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.

  • JFAM

    JFAM - 2011-01-06

    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.

  • Ptit_Bleu

    Ptit_Bleu - 2011-01-06

    Hello Jorismeys,

    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 (I have no such a problem with the latest Tinn-R version but I have
    'trPaths' message).
    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

    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,
    Ptit Bleu.

  • JFAM

    JFAM - 2011-01-06

    Ptit Bleu,

    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).

  • Ptit_Bleu

    Ptit_Bleu - 2011-01-06

    Relevant answer.
    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.
    Ptit Bleu.

  • JFAM

    JFAM - 2011-01-06

    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.

  • Ptit_Bleu

    Ptit_Bleu - 2011-01-06

    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 !
    Ptit Bleu.

  • Ptit_Bleu

    Ptit_Bleu - 2011-01-07

    Hello again,

    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,
    Ptit Bleu.

  • Ptit_Bleu

    Ptit_Bleu - 2011-01-11

    Copy of the post "Rgui vs Rterm" in the open discussion forum :

    Hi again,

    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 + Rgui 2.12.1 configuration is running well (it
    matches my expectations at least).
    Maybe it can help other people ...
    Ptit Bleu.

  • Adam Carr

    Adam Carr - 2011-01-18

    Good Morning:

    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 ( 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 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:

    Warning message:
    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',
    'lines.r'), sep='')

    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.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks