FAQ
Hello, everybody.

I apologize if this is obvious. I've not tried to make changes in R
code within the R source itself before.

I'm pursuing an experiment to make RPM files for R packages
on-the-fly. Any time I install an R package successfully, I want to
wrap up those files in an RPM. Basically, the idea is to "hack" an
option similar to --build for R CMD INSTALL.

I observe in the R source code this is the file that handles installs

src/library/tools/R/install.R

The R DESCRIPTION file has the information required and the code in
install.R is quite clear and easy to understand. I *think* I see what
I need to do.

But I don't understand how to test the effect of my changes without
re-compiling R and re-installing it.

In the installed R, there is no file "install.R", so there's no
obvious place to hack on it.

Is it actually necessary to recompile & re-install R every time I want
to test changes to that file?

pj
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

Search Discussions

  • Jens Elkner at Feb 18, 2010 at 8:20 pm
    On Thu, Feb 18, 2010 at 11:33:14AM -0600, Paul Johnson wrote:
    Hello, everybody.
    I apologize if this is obvious. I've not tried to make changes in R
    code within the R source itself before.

    I'm pursuing an experiment to make RPM files for R packages
    on-the-fly. Any time I install an R package successfully, I want to
    wrap up those files in an RPM. Basically, the idea is to "hack" an
    option similar to --build for R CMD INSTALL.
    Hmm, why not take the easy way:

    clean_dst $PROTO
    cd $TMPBUILD
    mkdir -p $PROTO/R/library
    $R_HOME/bin/R CMD INSTALL -l $PROTO/R/library $TMPBUILD

    $PROTO is the directory, where the R module gets installed (e.g. /tmp/R),
    $TMPBUILD is the directory with the R module sources (e.g. /tmp/build/quantreg)
    and the rest is obvious.

    Than you need to care about/package $PROTO/R/library, only.

    Built about 150 R packages this way 4 Solaris without any pkg problems ...

    Regards,
    jel.
    --
    Otto-von-Guericke University http://www.cs.uni-magdeburg.de/
    Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2
    39106 Magdeburg, Germany Tel: +49 391 67 12768
  • Paul Johnson at Feb 19, 2010 at 11:04 pm

    On Thu, Feb 18, 2010 at 2:20 PM, Jens Elkner wrote:
    On Thu, Feb 18, 2010 at 11:33:14AM -0600, Paul Johnson wrote:
    I'm pursuing an experiment to make RPM files for R packages
    on-the-fly. Any time I install an R package successfully, I want to
    wrap up those files in an RPM. ? Basically, the idea is to "hack" an
    option similar to --build for R CMD INSTALL.
    Hmm, why not take the easy way:

    ? ?clean_dst $PROTO
    ? ?cd $TMPBUILD
    ? ?mkdir -p $PROTO/R/library
    ? ?$R_HOME/bin/R CMD INSTALL -l $PROTO/R/library $TMPBUILD
    Yes, I've been there, done that.

    I have to administer this on 60 servers in a cluster. I don't want to
    rebuild all packages on all systems. If I can figure a way to create
    RPM for them, I can script the RPM installs and then I'm sure all the
    systems are identical.

    In the worst case scenario, I just have to copy the library tree from
    one machine to another. But the RPM approach has a bit more built-in
    error checking.

    pj
    --
    Paul E. Johnson
    Professor, Political Science
    1541 Lilac Lane, Room 504
    University of Kansas
  • Uwe Ligges at Feb 22, 2010 at 4:10 pm

    On 20.02.2010 00:04, Paul Johnson wrote:
    On Thu, Feb 18, 2010 at 2:20 PM, Jens Elknerwrote:
    On Thu, Feb 18, 2010 at 11:33:14AM -0600, Paul Johnson wrote:
    I'm pursuing an experiment to make RPM files for R packages
    on-the-fly. Any time I install an R package successfully, I want to
    wrap up those files in an RPM. Basically, the idea is to "hack" an
    option similar to --build for R CMD INSTALL.
    Hmm, why not take the easy way:

    clean_dst $PROTO
    cd $TMPBUILD
    mkdir -p $PROTO/R/library
    $R_HOME/bin/R CMD INSTALL -l $PROTO/R/library $TMPBUILD
    Yes, I've been there, done that.

    I have to administer this on 60 servers in a cluster. I don't want to
    rebuild all packages on all systems. If I can figure a way to create
    RPM for them, I can script the RPM installs and then I'm sure all the
    systems are identical.

    In the worst case scenario, I just have to copy the library tree from
    one machine to another. But the RPM approach has a bit more built-in
    error checking.

    pj

    Paul,

    beside the already answered parts: in general I'd try to read from some
    network space so that I'd had to make only 1 installation which is also
    useful for easier upgrades and parallel execution where you need
    identical doftware on all nodes.

    Best,
    Uwe
  • Duncan Murdoch at Feb 21, 2010 at 5:36 pm

    Paul Johnson wrote:
    Hello, everybody.

    I apologize if this is obvious. I've not tried to make changes in R
    code within the R source itself before.

    I'm pursuing an experiment to make RPM files for R packages
    on-the-fly. Any time I install an R package successfully, I want to
    wrap up those files in an RPM. Basically, the idea is to "hack" an
    option similar to --build for R CMD INSTALL.

    I observe in the R source code this is the file that handles installs

    src/library/tools/R/install.R

    The R DESCRIPTION file has the information required and the code in
    install.R is quite clear and easy to understand. I *think* I see what
    I need to do.

    But I don't understand how to test the effect of my changes without
    re-compiling R and re-installing it.

    In the installed R, there is no file "install.R", so there's no
    obvious place to hack on it.

    Is it actually necessary to recompile & re-install R every time I want
    to test changes to that file?
    The source to most packages is parsed and saved in binary images which
    are loaded as necessary by R. So install.R has been parsed and included
    in library/tools/R/tools.rdb.

    Debugging system functions can be a little tedious. In some cases you
    can create new copies of the functions in your workspace; set their
    environment to the environment of the original function, and they'll
    work properly. The main difficulty is that other functions in the
    package won't see your version, they'll see the original (as will your
    own, if it calls itself recursively.)

    You can replace the original function in the package namespace using
    assign(), but you need to handle unlocking and locking of bindings.

    Normally I'd recommend just editing the source and running make to
    incorporate the changes; it's too easy to miss a step if you try to take
    shortcuts, and then you need to debug your edits, not just your code.

    Duncan Murdoch
    pj

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupr-devel @
categoriesr
postedFeb 18, '10 at 5:33p
activeFeb 22, '10 at 4:10p
posts5
users4
websiter-project.org
irc#r

People

Translate

site design / logo © 2022 Grokbase