Re: [R-pkg-devel] What to do when you can't reproduce CRAN R CMD check unit test failures?
Of course the Great And Powerful Ushey did the super-smart thing and actually tested the code locally. Apologies for not thinking of doing the same on my end (though I'm also OS X): > getwd() [1] "/Users/bob/Development/pathological" > test() Loading pathological Loading required package: testthat Testing pathological ..1..2..W... Warnings --- 1. copy_dir works with recursive = TRUE (@test_dir_copy.R#34) - The files ‘javaconf’, ‘ldpaths’, ‘Makeconf’, ‘Renviron’, ‘repositories’ were not copied successfully. Failed - 1. Failure: decompose_path handles missing paths. (@test_decompose_path.R#279) - `warnings` does not match "Coercing .+ to class [[:punct:]]character[[:punct:]]\\.". Actual value: "Coercing x to class ‘character’." 2. Failure: decompose_path works with a factor input. (@test_decompose_path.R#329) `warnings` does not match "Coercing .+ to class [[:punct:]]character[[:punct:]]\\.". Actual value: "Coercing x to class ‘character’." DONE === I'm using R version 3.3.0 RC (2016-05-01 r70572) & testthat 1.0.2 (2016-04-23 CRAN (R 3.3.0) I also get those same two errors on a slightly out-of-date R-devel on Ubuntu. On Thu, May 12, 2016 at 2:09 AM, Kevin Ushey wrote: > Is it possible that `getwd()` is reporting something on the CRAN build > servers that your `decompose_path()` doesn't handle? For example, your > tests fail for me if I run them while in the root directory (on OS X). > > Kevin > > On Thu, May 12, 2016 at 12:37 AM, Richard Cotton > wrote: >> Thanks Bob, >> >> I'd forgotten about the option to run win-builder against R-devel. >> >> Though it seems that in this case, all the tests are passing there too. >> >> http://win-builder.r-project.org/21kc9XGKdANF/examples_and_tests/tests_i386/testthat.Rout >> http://win-builder.r-project.org/21kc9XGKdANF/examples_and_tests/tests_x64/testthat.Rout >> >> I'm now completely out of ideas as to where the problem could be. >> >> >> On 11 May 2016 at 15:46, boB Rudis wrote: >>> did you try winbuilder R-devel? I occasionally (ok, often) forget to >>> do that and it sometimes kick out different errors than R-devel on >>> local systems. >>> >>> On Wed, May 11, 2016 at 2:40 AM, Richard Cotton >>> wrote: Yesterday I uploaded a new version of the pathological package to CRAN. It was initially accepted but today I got a message saying that some of the tests for the decompose_path function are failing under Windows. I've tested the package on a local Windows 10 machine with R-3.3.0 and R-devel, and in Win 7 and Win 8 compatibility modes, and on Windows Server 2012 via AppVeyor. In all cases, all the tests pass. I tried the CRAN win builder service today, and again, all tests pass. http://win-builder.r-project.org/0ZrX4I75nvzM/examples_and_tests/tests_i386/testthat.Rout http://win-builder.r-project.org/0ZrX4I75nvzM/examples_and_tests/tests_x64/testthat.Rout The failure portion of the output I got from Uwe is as follows: * checking tests ... ERROR Running the tests in 'tests/testthat.R' failed. Last 13 lines of output: 1. Failure: decompose_path handles paths with no directory and a single extension in the filename. (@test_decompose_path.R#42) 2. Failure: decompose_path handles paths with no directory and a double extension in the filename. (@test_decompose_path.R#72) 3. Failure: decompose_path handles paths with no directory and no extension in the filename. (@test_decompose_path.R#103) 4. Failure: decompose_path handles filenames containing a '.' and an extension. (@test_decompose_path.R#133) 5. Failure: decompose_path handles the current directory as '.'. (@test_decompose_path.R#221) 6. Failure: decompose_path handles the parent directory as '..'. (@test_decompose_path.R#236) 7. Failure: decompose_path handles files inside '.'. (@test_decompose_path.R#251) 8. Failure: decompose_path works with a character vector input. (@test_decompose_path.R#321) 9. Failure: decompose_path works with a factor input. (@test_decompose_path.R#333) 1. ... Since this isn't hugely informative as to the problem, I'd like general advice on how I can diagnose a failing test when I can't reproduce it. It would also be useful if anyone can run R CMD check and see if they find test failures. The CRAN release is here (the problematic version is 0.0-8): https://cran.r-project.org/web/packages/pathological and t
Re: [R-pkg-devel] What to do when you can't reproduce CRAN R CMD check unit test failures?
On Thu, 2016-05-12 at 01:09 -0500, Kevin Ushey wrote:
> Is it possible that `getwd()` is reporting something on the CRAN
> build
> servers that your `decompose_path()` doesn't handle? For example,
> your
> tests fail for me if I run them while in the root directory (on OS
> X).
It does not work on a Windows shared drive:
> setwd("//vboxsrv/duchamp")
> getwd()
[1] "vboxsrv/duchamp"
whereas:
> decompose_path("foo.tgz")
dirname filename extension
foo.tgz //vboxsrv/duchamp foo tgz
Martyn
> Kevin
>
> On Thu, May 12, 2016 at 12:37 AM, Richard Cotton om> wrote:
> >
> > Thanks Bob,
> >
> > I'd forgotten about the option to run win-builder against R-devel.
> >
> > Though it seems that in this case, all the tests are passing there
> > too.
> >
> > http://win-builder.r-project.org/21kc9XGKdANF/examples_and_tests/te
> > sts_i386/testthat.Rout
> > http://win-builder.r-project.org/21kc9XGKdANF/examples_and_tests/te
> > sts_x64/testthat.Rout
> >
> > I'm now completely out of ideas as to where the problem could be.
> >
> >
> > On 11 May 2016 at 15:46, boB Rudis wrote:
> > >
> > > did you try winbuilder R-devel? I occasionally (ok, often) forget
> > > to
> > > do that and it sometimes kick out different errors than R-devel
> > > on
> > > local systems.
> > >
> > > On Wed, May 11, 2016 at 2:40 AM, Richard Cotton > > l.com> wrote:
> > > >
> > > > Yesterday I uploaded a new version of the pathological package
> > > > to
> > > > CRAN. It was initially accepted but today I got a message
> > > > saying that
> > > > some of the tests for the decompose_path function are failing
> > > > under
> > > > Windows.
> > > >
> > > > I've tested the package on a local Windows 10 machine with R-
> > > > 3.3.0 and
> > > > R-devel, and in Win 7 and Win 8 compatibility modes, and on
> > > > Windows
> > > > Server 2012 via AppVeyor. In all cases, all the tests pass.
> > > >
> > > > I tried the CRAN win builder service today, and again, all
> > > > tests pass.
> > > > http://win-builder.r-project.org/0ZrX4I75nvzM/examples_and_test
> > > > s/tests_i386/testthat.Rout
> > > > http://win-builder.r-project.org/0ZrX4I75nvzM/examples_and_test
> > > > s/tests_x64/testthat.Rout
> > > >
> > > > The failure portion of the output I got from Uwe is as follows:
> > > >
> > > > * checking tests ... ERROR
> > > > Running the tests in 'tests/testthat.R' failed.
> > > > Last 13 lines of output:
> > > > 1. Failure: decompose_path handles paths with no directory
> > > > and a
> > > > single extension in the filename. (@test_decompose_path.R#42)
> > > > 2. Failure: decompose_path handles paths with no directory
> > > > and a
> > > > double extension in the filename. (@test_decompose_path.R#72)
> > > > 3. Failure: decompose_path handles paths with no directory
> > > > and no
> > > > extension in the filename. (@test_decompose_path.R#103)
> > > > 4. Failure: decompose_path handles filenames containing a '.'
> > > > and an
> > > > extension. (@test_decompose_path.R#133)
> > > > 5. Failure: decompose_path handles the current directory as
> > > > '.'.
> > > > (@test_decompose_path.R#221)
> > > > 6. Failure: decompose_path handles the parent directory as
> > > > '..'.
> > > > (@test_decompose_path.R#236)
> > > > 7. Failure: decompose_path handles files inside '.'.
> > > > (@test_decompose_path.R#251)
> > > > 8. Failure: decompose_path works with a character vector
> > > > input.
> > > > (@test_decompose_path.R#321)
> > > > 9. Failure: decompose_path works with a factor input.
> > > > (@test_decompose_path.R#333)
> > > > 1. ...
> > > >
> > > >
> > > > Since this isn't hugely informative as to the problem, I'd like
> > > > general advice on how I can diagnose a failing test when I
> > > > can't
> > > > reproduce it.
> > > >
> > > > It would also be useful if anyone can run R CMD check and see
> > > > if they
> > > > find test failures.
> > > >
> > > > The CRAN release is here (the problematic version is 0.0-8):
> > > > https://cran.r-project.org/web/packages/pathological
> > > >
> > > > and the github version is currently in the same state,
> > > > available here:
> > > > https://github.com/richierocks/pathological
> > > >
> > > > --
> > > > Regards,
> > > > Richie
> > > >
> > > > Learning R
> > > > 4dpiecharts.com
> > > >
> > > > __
> > > > R-package-devel@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> >
> > --
> > Regards,
> > Richie
> >
> > Learning R
> > 4dpiecharts.com
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel---
This message and its attachments are strictly co
[R-pkg-devel] Object getter, Am I doing this right?
All,
I am creating getters and setters for my package which uses S4. To research
getters and setters, I have been looking at the bio conductor website and
documentation provided therein. I came up with the below as a getter for the
object PassThrough. This works PrepaidPrin(PassThrough).
The passthrough object has 50 slots and I have on the order of about 35 new
classes. Some of which are subclasses as well. Thus, PrepaidPrin is also a
slot in another class ScenarioTotalReturn. So, I need multiple dispatch but I
am still research that. Before I started down this road I thought I would
solicit opinions as to what I propose to make sure I have the basics correct.
Best,
Glenn
#' A standard generic function to access the slot PrepaidPrin
#' @param object an object whose method signature is PassThrough
#' @export
setGeneric("PrepaidPrin", function(object)
{standardGeneric("PrepaidPrin")})
#' Method to extract Prepaid Principal from class PassThrough
#' @param object the name of the object of type PassThrough
#' @exportMethod PrepaidPrin
setMethod("PrepaidPrin", signature("PassThrough"),
function(object){object@PrepaidPrin})
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] develop package with lots of tcltk in it
On 11 May 2016 at 12:56, Dalthorp, Daniel wrote: | I have an R/tcltk application that is designed for use primarily by people | who don't know R and don't care to learn much about it. I'd like users to | be able to use the software with a bare minimum interaction with R. | | Although the application has some 15000 lines of code in a couple dozen .R | files, in essence I don't think it's much more than an elaborate version of | the following: | | library(tcltk) | tt <- tktoplevel() # a required container for tk objects (textboxes, | radiobuttons, data tables, etc.) | tk.x <- tclVar() # a tcl version of user variable x | x.edit <- tkentry(tt, textvariable = tk.x, width = 5) # box for user to | enter x value | x.lbl <- tklabel(tt, text = "Enter x value: ") # a fixed label | xcalc <- tkbutton(tt, text = "Calculate", command = function() | tkmessageBox(message = tclvalue(tk.x))) # button that prints x to R console | tkgrid(x.lbl, x.edit, xcalc) # a function that puts the textbox, label, and | button onto the tk window | | The following doesn't work: | # tt, x.edit, x.lbl, xcalc all seem to me like an R objects that will not | be modified, so I tried | devtools::use_data(tt, x.edit, x.lbl, xcalc, internal = F, overwrite=T) # | (after defining them) | # tk.x is a variable that I want to assign a value to at the beginning, but | user can later change the value: | devtools::use_data(tt, x.edit, x.lbl, xcalc, internal = F, overwrite=T) | | The following does work, but it is not a good solution: | (1) define working directory as package/data | (2) create new tk windows via tkbutton commands = function() | source(filename) | This forces the user to use a pre-defined working directory. My application | fills that wd with several hundred functions and variables. If user changes | wd or changes values of variables that my app needs, the program crashes. | | Any help would be greatly appreciated! I haven't seen the obvious stated: Have you looked into creating a package? It can contain as much tcl/tk support code as you like, etc pp. And as you state you have '15000 lines of code in a couple dozen .R files' you are well passed the point where a package really is the best choice. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] develop package with lots of tcltk in it
Thanks, Dirk.
Sorry for my lack of clarity. I do want to create a package and have
created one and it works, but the structure is awkward. I'm hoping someone
can help me straighten out the organization.
In package/R folder, I have several files that define standalone functions
that crunch data.
In package/data folder, I have several source files that construct
appropriate tktoplevel() windows with the desired widgets
To start the application, user opens a main tktoplevel() window by entering
a simple command from R.
That main window has several buttons that source() files in package/data
folder to build a new tktoplevel(), depending on user choice
For users who don't know anything about R, this solution may work fine. But
for users that do know R, it is unsatisfactory...program changes the
working directory, fills it with hundreds of alien-looking functions and
data, and crashes if working directory is changed or variables are modified
by hand.
I came up with that goofy solution to get around two issues:
1. I wasn't able to get away with defining tktoplevel windows with
associated widgets and storing in .Rda's packaged in /data or as
devtools::use_data(...internal = T), so I figured they needed to be defined
and created as needed;
2. it is easy to define the tktoplevels via code in source() files, but I
was having trouble with scoping and bookkeeping issues when trying to
define them via functions instead. It would be convenient to have all the
interesting data stored as globals and use the tkwidgets to edit and
manipulate them without having to think specifically about how to pass the
interesting data back and forth.
E.g. is there an easy way to organize the following into a package that
does not use 'source', treats tk.x and tk.y as globals, and does not take
over the user's working directory with a bunch of variables like tt1,
x.edit, tk.x, tk.y, etc.?
tt1 <- tktoplevel()
tk.x <- tclVar()
x.edit <- tkentry(tt1, textvariable = tk.x, width = 5)
x.lbl <- tklabel(tt1, text = "Enter x value: ")
xcalc <- tkbutton(tt1, text = "Calculate", command = function()
tkmessageBox(message = tclvalue(tk.x)))
doMoreStuff <- tkbutton(tt1, text = "Do more...", command = function()
source('doStuff_form.R'))
tkgrid(x.lbl, x.edit)
tkgrid(xcalc,doMoreStuff)
# in doStuff_form.R:
tt2 <- tktoplevel()
tk.y<-tclVar()
y.edit<- tkentry(tt2, textvariable = tk.y, width = 5)
anscalc <- tkbutton(tt2, text = "calculate answer", command = function()
tkmessageBox(message=as.numeric(tclvalue(tk.y)) *
as.numeric(tclvalue(tk.x)))
)
tkgrid(y.edit, anscalc)
-Dan
On Thu, May 12, 2016 at 8:30 AM, Dirk Eddelbuettel wrote:
>
> On 11 May 2016 at 12:56, Dalthorp, Daniel wrote:
> | I have an R/tcltk application that is designed for use primarily by
> people
> | who don't know R and don't care to learn much about it. I'd like users to
> | be able to use the software with a bare minimum interaction with R.
> |
> | Although the application has some 15000 lines of code in a couple dozen
> .R
> | files, in essence I don't think it's much more than an elaborate version
> of
> | the following:
> |
> | library(tcltk)
> | tt <- tktoplevel() # a required container for tk objects (textboxes,
> | radiobuttons, data tables, etc.)
> | tk.x <- tclVar() # a tcl version of user variable x
> | x.edit <- tkentry(tt, textvariable = tk.x, width = 5) # box for user to
> | enter x value
> | x.lbl <- tklabel(tt, text = "Enter x value: ") # a fixed label
> | xcalc <- tkbutton(tt, text = "Calculate", command = function()
> | tkmessageBox(message = tclvalue(tk.x))) # button that prints x to R
> console
> | tkgrid(x.lbl, x.edit, xcalc) # a function that puts the textbox, label,
> and
> | button onto the tk window
> |
> | The following doesn't work:
> | # tt, x.edit, x.lbl, xcalc all seem to me like an R objects that will not
> | be modified, so I tried
> | devtools::use_data(tt, x.edit, x.lbl, xcalc, internal = F, overwrite=T) #
> | (after defining them)
> | # tk.x is a variable that I want to assign a value to at the beginning,
> but
> | user can later change the value:
> | devtools::use_data(tt, x.edit, x.lbl, xcalc, internal = F, overwrite=T)
> |
> | The following does work, but it is not a good solution:
> | (1) define working directory as package/data
> | (2) create new tk windows via tkbutton commands = function()
> | source(filename)
> | This forces the user to use a pre-defined working directory. My
> application
> | fills that wd with several hundred functions and variables. If user
> changes
> | wd or changes values of variables that my app needs, the program crashes.
> |
> | Any help would be greatly appreciated!
>
> I haven't seen the obvious stated: Have you looked into creating a
> package?
>
> It can contain as much tcl/tk support code as you like, etc pp. And as
> you
> state you have '15000 lines of code in a couple dozen .R files' you are
> well
> passed the point where a package really is the best choice.
>
> Dirk
>
> --
> http://dirk.eddelbuett
Re: [R-pkg-devel] develop package with lots of tcltk in it
>
> "For users who don't know anything about R, this solution may work fine.
> But
> for users that do know R, it is unsatisfactory...program changes the
> working directory, fills it with hundreds of alien-looking functions and
> data, and crashes if working directory is changed or variables are modified
> by hand."
Is this something that can be solved with an environment inside of the
package? I've done this in the past with good results. Check out Dirk's
rpushbullet for an example:
https://github.com/eddelbuettel/rpushbullet/blob/master/R/init.R
the first line of code he sets one up
.pkgenv <- new.env(parent=emptyenv())
and then creates and access objects inside of that throughout the rest of
the package.
On Thu, May 12, 2016 at 1:25 PM, Dalthorp, Daniel
wrote:
> Thanks, Dirk.
>
> Sorry for my lack of clarity. I do want to create a package and have
> created one and it works, but the structure is awkward. I'm hoping someone
> can help me straighten out the organization.
>
> In package/R folder, I have several files that define standalone functions
> that crunch data.
> In package/data folder, I have several source files that construct
> appropriate tktoplevel() windows with the desired widgets
> To start the application, user opens a main tktoplevel() window by entering
> a simple command from R.
> That main window has several buttons that source() files in package/data
> folder to build a new tktoplevel(), depending on user choice
>
> For users who don't know anything about R, this solution may work fine. But
> for users that do know R, it is unsatisfactory...program changes the
> working directory, fills it with hundreds of alien-looking functions and
> data, and crashes if working directory is changed or variables are modified
> by hand.
>
> I came up with that goofy solution to get around two issues:
> 1. I wasn't able to get away with defining tktoplevel windows with
> associated widgets and storing in .Rda's packaged in /data or as
> devtools::use_data(...internal = T), so I figured they needed to be defined
> and created as needed;
> 2. it is easy to define the tktoplevels via code in source() files, but I
> was having trouble with scoping and bookkeeping issues when trying to
> define them via functions instead. It would be convenient to have all the
> interesting data stored as globals and use the tkwidgets to edit and
> manipulate them without having to think specifically about how to pass the
> interesting data back and forth.
>
> E.g. is there an easy way to organize the following into a package that
> does not use 'source', treats tk.x and tk.y as globals, and does not take
> over the user's working directory with a bunch of variables like tt1,
> x.edit, tk.x, tk.y, etc.?
> tt1 <- tktoplevel()
> tk.x <- tclVar()
> x.edit <- tkentry(tt1, textvariable = tk.x, width = 5)
> x.lbl <- tklabel(tt1, text = "Enter x value: ")
> xcalc <- tkbutton(tt1, text = "Calculate", command = function()
> tkmessageBox(message = tclvalue(tk.x)))
> doMoreStuff <- tkbutton(tt1, text = "Do more...", command = function()
> source('doStuff_form.R'))
> tkgrid(x.lbl, x.edit)
> tkgrid(xcalc,doMoreStuff)
>
> # in doStuff_form.R:
> tt2 <- tktoplevel()
> tk.y<-tclVar()
> y.edit<- tkentry(tt2, textvariable = tk.y, width = 5)
> anscalc <- tkbutton(tt2, text = "calculate answer", command = function()
> tkmessageBox(message=as.numeric(tclvalue(tk.y)) *
> as.numeric(tclvalue(tk.x)))
> )
> tkgrid(y.edit, anscalc)
>
> -Dan
>
> On Thu, May 12, 2016 at 8:30 AM, Dirk Eddelbuettel wrote:
>
> >
> > On 11 May 2016 at 12:56, Dalthorp, Daniel wrote:
> > | I have an R/tcltk application that is designed for use primarily by
> > people
> > | who don't know R and don't care to learn much about it. I'd like users
> to
> > | be able to use the software with a bare minimum interaction with R.
> > |
> > | Although the application has some 15000 lines of code in a couple dozen
> > .R
> > | files, in essence I don't think it's much more than an elaborate
> version
> > of
> > | the following:
> > |
> > | library(tcltk)
> > | tt <- tktoplevel() # a required container for tk objects (textboxes,
> > | radiobuttons, data tables, etc.)
> > | tk.x <- tclVar() # a tcl version of user variable x
> > | x.edit <- tkentry(tt, textvariable = tk.x, width = 5) # box for user to
> > | enter x value
> > | x.lbl <- tklabel(tt, text = "Enter x value: ") # a fixed label
> > | xcalc <- tkbutton(tt, text = "Calculate", command = function()
> > | tkmessageBox(message = tclvalue(tk.x))) # button that prints x to R
> > console
> > | tkgrid(x.lbl, x.edit, xcalc) # a function that puts the textbox, label,
> > and
> > | button onto the tk window
> > |
> > | The following doesn't work:
> > | # tt, x.edit, x.lbl, xcalc all seem to me like an R objects that will
> not
> > | be modified, so I tried
> > | devtools::use_data(tt, x.edit, x.lbl, xcalc, internal = F,
> overwrite=T) #
> > | (after defining them)
> > | # tk.x is a variable that I want to assign a value to
