Re: [Rd] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())

[Deepayan Sarkar]

On Wed, May 10, 2017 at 2:36 AM, William Dunlap via R-devel
 wrote:
> Some formula methods for S3 generic functions use the idiom
> returnValue$call <- sys.call(sys.parent())
> to show how to recreate the returned object or to use as a label on a
> plot.  It is often followed by
>  returnValue$call[[1]] <- quote(myName)
> E.g., I see it in packages "latticeExtra" and "leaps", and I suspect it
> used in "lattice" as well.
>
> This idiom has not done good things for quite a while (ever?) but I noticed
> while running tests that it acts differently in R-3.4.0 than in R-3.3.3.
> Neither the old or new behavior is nice.  E.g., in R-3.3.3 we get
>
>> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> envir=new.env())
> xyplot(expr, envir, enclos)
>
> and
>
>> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> envir=new.env())
> xyplot(expr, envir, enclos)
>
> while in R-3.4.0 we get
>> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> envir=new.env())
> xyplot(parse(text = text), envir = envir)
>
> and
>
>> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> envir=new.env())
> xyplot(call, envir = envir)
>
> Should these packages be be fixed up to use just sys.call()?

I admit to not understanding these things very well, but I'll try to
explain why I ended up with the usage I have. The main use of the
$call component within lattice is to use it in the summary method, as
in:

> summary(xyplot(mpg~hp, data=mtcars))

Call:
xyplot(mpg ~ hp, data = mtcars)

Number of observations:
[1] 32

Here is a minimal approximation to what I need: Here foo() and bar()
are generics producing objects of class "foobar", bar() calls foo()
with one argument changed, and the print() method for "foobar" is just
supposed to print the call that produced it:



foo <- function(x, ...) UseMethod("foo")
bar <- function(x, ...) UseMethod("bar")
print.foobar <- function(x, ...) print(x$call)

## Using plain sys.call():

foo.formula <- function(x, ...)
{
ans <- structure(list(), class = "foobar")
ans$call <- sys.call()
ans
}

bar.formula <- function(x, ..., panel)
{
foo.formula(x, ..., panel = panel.bar)
}

foo.table <- function(x, ...)
{
ans <- foo.formula(Freq ~ Var1,
   as.data.frame.table(x), ...)
ans
}

## I would get

foo(y ~ x)
# foo.formula(y ~ x)

bar(y ~ x)
# foo.formula(x, ..., panel = panel.bar)

foo(as.table(1:10))
# foo.formula(Freq ~ Var1, as.data.frame.table(x), ...)

## The last two are improved by

foo.formula <- function(x, ...)
{
ans <- structure(list(), class = "foobar")
ans$call <- sys.call(sys.parent())
ans
}

bar(y ~ x)
## bar.formula(y ~ x)

foo(as.table(1:10))
## foo.table(as.table(1:10))



Adding

ans$call[[1]] <- quote(foo)

(or quote(bar) in bar.formula) is needed to replace the unexported
method name (foo.formula) with the generic name (foo), but that's
probably not the problem.

With this approach in lattice,

p <- some.function(...)
eval(p$call)

usually works, but not always, if I remember correctly.

I'm happy to consider more robust solutions. Maybe I just need to have a

...$call <- sys.call()

statement in every method?

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] bug report: nlme model-fitting crashes with R 3.4.0

[Erwan Le Pennec]

Dear all,

I've stumbled a similar issue with the package cluster when 
compiling the 3.4.0 version with the settings of Fedora RPM specs. 
Compiling R with the default setting of configure yields a version that 
works for cluster... and nlme.


I did not find the exact option that was the cause of this issue 
but I'm willing to help.


Erwan

PS: This is the reason why R is still at version 3.3.3 on the Fedora 
distribution.


On 10/05/17 22:59, Langbehn, Douglas wrote:

lme() and gls() models from the nlme package are all crashing with R.3.4.0. 
Identical code ran correctly, without error in R 3.3.3 and earlier versions.  
The behavior is easily demonstrated using one of the examples form the lme() 
help file, along with two simple variants. I have commented the errors 
generated by these calls, as well as the lines of code generating them, in the 
code example below.

As of today, this bug had not been reported on the R Bugzilla page. I could not submit 
this report directly to the page because I am not a member, and , as explained in the 
"Reporting Bugs" link from the  R home page, membership has now been closed due 
to spamming problems..


library(nlme)
#Using version 3.1-131
#Windows 7 64-bit operating system

fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~ 1)

# Error in array(c(rep(1, p), .C(inner_perc_table, as.double(X), 
as.integer(unlist(grps)),  :
# object 'inner_perc_table' not found
#
#Upon debugging, this error is thrown with line 135 of lme.formula() code.
#
#fixDF <- getFixDF(X, grps, attr(lmeSt, "conLin")$dims$ngrps,

lme(distance ~ age + Sex, data = Orthodont, random = ~ 1|Subject)

# Error in array(c(rep(1, p), .C(inner_perc_table, as.double(X), 
as.integer(unlist(grps)),  :
# object 'inner_perc_table' not found

gls(distance ~ age + Sex, data = Orthodont,
 correlation = corCompSymm( form = ~ 1 | Subject))

# Error in corMatrix.corCompSymm(object) :
# object 'compSymm_matList' not found
#
#Upon debugging, the error is thrown by line 60 of gls code
#
#glsSt <- Initialize(glsSt, dataMod, glsEstControl)

R.version

# _
# platform   x86_64-w64-mingw32
# arch   x86_64
# os mingw32
# system x86_64, mingw32
# status
# major  3
# minor  4.0
# year   2017
# month  04
# day21
# svn rev72570
# language   R
# version.string R version 3.4.0 (2017-04-21)
# nickname   You Stupid Darkness


Douglas R Langbehn MD, PhD
Professor
Dept. of Psychiatry and Biostatistics (secondary)
University of Iowa Carver College of Medicine
douglas-langb...@uiowa.edu




Notice: This UI Health Care e-mail (including attachments) is covered by the 
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is intended only 
for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential, and exempt from 
disclosure under applicable law. If you are not the intended recipient, any 
dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify the 
sender immediately and delete or destroy all copies of the original message and 
attachments thereto. Email sent to or from UI Health Care may be retained as 
required by law or regulation. Thank you.


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] xrealloc namespace conflict

[Patrick Perry]

I've done a bit more investigation into this issue. Here is my current 
understanding of the situation:

1. I have a package on CRAN (corpus-0.3.1) that passes tests on all 
platforms except for Linux.
2. My package defines a C function, "xrealloc", for internal use.
3. The libreadline library that R links to defines a different version 
of "xrealloc".
4. On Linux, when I load my package, references to "xrealloc" get linked 
to the libreadline version of that function.
5. This causes one of my tests to fail, calling exit(2), because the 
libreadline version of xrealloc does not allow calls of the form 
"xrealloc(ptr, 0)".

I can work around this issue pretty easily, by either renaming my 
version of xrealloc to something else, or by avoiding calls of the form 
"xrealloc(ptr, 0)". So, this is not a major issue, but it's a little 
unsettling to see this behavior when my package does not explicitly link 
to or use anything from libreadline.

Is there a reason this behavior is only manifesting on Linux? Is there 
something wrong with the way I'm compiling my package on that platform? 
Is this just some quirk about the way R is loading dynamic libraries on 
Linux? I'd appreciate any insight into the issue.


Patrick

p.s. Here are some references:

My package Makevars are at 
https://github.com/patperry/r-corpus/blob/master/src/Makevars ; my 
version of "xrealloc" is in corpus/src/xalloc.c

You can see the source for the libreadline xrealloc at 
https://github.com/JuliaLang/readline/blob/master/xmalloc.c#L67


Patrick Perry wrote:
>
> I have a package on CRAN now (corpus-0.3.1) that is currently failing
> tests on Linux, but passing on all other architectures:
>
> https://cran.r-project.org/web/checks/check_results_corpus.html
>
> I believe that the issue arrises from a namespace class between
> "xrealloc", which my package provides for internal use, but which R
> also seems to provide (possibly as part of TRE in
> src/extra/tre/xmalloc.c). It looks like my package is not picking up
> my custom xrealloc, but using an xrealloc provided by R.
>
> Besides the fact that I am linking to the wrong xrealloc, I think my
> tests are failing for the same reason that the following code
> segfaults on Linux (Debian, with R 3.4.0):
>
> test <- inline::cfunction(language='C',
> otherdefs='void *xmalloc(size_t); void *xrealloc(void *, size_t);',
> body = 'void *ptr = xmalloc(256); xrealloc(ptr, 0); return
> R_NilValue;')
> test()
> ## xrealloc: out of virtual memory
>
> It seems that the R xrealloc doesn't like being given a size of 0,
> even though this behavior is well-defined for realloc (it should free
> the memory). Based on my failing CRAN tests, it looks like this is a
> Linux-specific issue.
>
> Is there a way to modify my Makevars to force the linker to choose my
> version of xrealloc for my package-specific code? My current Makevars
> are at https://github.com/patperry/r-corpus/blob/master/src/Makevars
>
> Thanks in advance for any help.
>
>
> Patrick


> Patrick Perry 
> May 6, 2017 at 5:36 PM
> I have a package on CRAN now (corpus-0.3.1) that is currently failing 
> tests on Linux, but passing on all other architectures:
>
> https://cran.r-project.org/web/checks/check_results_corpus.html
>
> I believe that the issue arrises from a namespace class between 
> "xrealloc", which my package provides for internal use, but which R 
> also seems to provide (possibly as part of TRE in 
> src/extra/tre/xmalloc.c). It looks like my package is not picking up 
> my custom xrealloc, but using an xrealloc provided by R.
>
> Besides the fact that I am linking to the wrong xrealloc, I think my 
> tests are failing for the same reason that the following code 
> segfaults on Linux (Debian, with R 3.4.0):
>
> test <- inline::cfunction(language='C',
> otherdefs='void *xmalloc(size_t); void *xrealloc(void *, size_t);',
> body = 'void *ptr = xmalloc(256); xrealloc(ptr, 0); return 
> R_NilValue;')
> test()
> ## xrealloc: out of virtual memory
>
> It seems that the R xrealloc doesn't like being given a size of 0, 
> even though this behavior is well-defined for realloc (it should free 
> the memory). Based on my failing CRAN tests, it looks like this is a 
> Linux-specific issue.
>
> Is there a way to modify my Makevars to force the linker to choose my 
> version of xrealloc for my package-specific code? My current Makevars 
> are at https://github.com/patperry/r-corpus/blob/master/src/Makevars
>
> Thanks in advance for any help.
>
>
> Patrick
>


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] xrealloc namespace conflict

[Dirk Eddelbuettel]

On 11 May 2017 at 12:16, Patrick Perry wrote:
| I've done a bit more investigation into this issue. Here is my current 
| understanding of the situation:
| 
| 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all 
| platforms except for Linux.
| 2. My package defines a C function, "xrealloc", for internal use.
| 3. The libreadline library that R links to defines a different version 
| of "xrealloc".
| 4. On Linux, when I load my package, references to "xrealloc" get linked 
| to the libreadline version of that function.
| 5. This causes one of my tests to fail, calling exit(2), because the 
| libreadline version of xrealloc does not allow calls of the form 
| "xrealloc(ptr, 0)".
| 
| I can work around this issue pretty easily, by either renaming my 
| version of xrealloc to something else, or by avoiding calls of the form 
| "xrealloc(ptr, 0)". So, this is not a major issue, but it's a little 
| unsettling to see this behavior when my package does not explicitly link 
| to or use anything from libreadline.
| 
| Is there a reason this behavior is only manifesting on Linux? Is there 
| something wrong with the way I'm compiling my package on that platform? 
| Is this just some quirk about the way R is loading dynamic libraries on 
| Linux? I'd appreciate any insight into the issue.

It may just be the flat namespace and linking order. AFAIK there is nothing
in C preventing so maybe you 'just got lucky' on the other platforms. See eg
http://stackoverflow.com/questions/7998770/

But then I don't use pure C that after anymore ... and in C++ you could just
wrap a namespace around your code, avoiding the issue.


Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] bug report: nlme model-fitting crashes with R 3.4.0

[Dirk Eddelbuettel]

On 11 May 2017 at 10:17, Erwan Le Pennec wrote:
|  Dear all,
| 
|  I've stumbled a similar issue with the package cluster when 
| compiling the 3.4.0 version with the settings of Fedora RPM specs. 
| Compiling R with the default setting of configure yields a version that 
| works for cluster... and nlme.
| 
|  I did not find the exact option that was the cause of this issue 
| but I'm willing to help.
| 
|  Erwan
| 
| PS: This is the reason why R is still at version 3.3.3 on the Fedora 
| distribution.
| 
| On 10/05/17 22:59, Langbehn, Douglas wrote:
| > lme() and gls() models from the nlme package are all crashing with R.3.4.0. 
Identical code ran correctly, without error in R 3.3.3 and earlier versions.  
The behavior is easily demonstrated using one of the examples form the lme() 
help file, along with two simple variants. I have commented the errors 
generated by these calls, as well as the lines of code generating them, in the 
code example below.
| >
| > As of today, this bug had not been reported on the R Bugzilla page. I could 
not submit this report directly to the page because I am not a member, and , as 
explained in the "Reporting Bugs" link from the  R home page, membership has 
now been closed due to spamming problems..
| >
| > 
| > library(nlme)
| > #Using version 3.1-131
| > #Windows 7 64-bit operating system
| >
| > fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~ 1)
| >
| > # Error in array(c(rep(1, p), .C(inner_perc_table, as.double(X), 
as.integer(unlist(grps)),  :
| > # object 'inner_perc_table' not found

That is a known issue with R 3.4.0 -- see NEWS.

Packages using .C and .Fortran _must_ be recompiled for R 3.4.0. If and when
you do, the example will work again.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] bug report: nlme model-fitting crashes with R 3.4.0

[Martyn Plummer]

On Thu, 2017-05-11 at 06:37 -0500, Dirk Eddelbuettel wrote:
> On 11 May 2017 at 10:17, Erwan Le Pennec wrote:
> >  Dear all,
> > 
> >  I've stumbled a similar issue with the package cluster when 
> > compiling the 3.4.0 version with the settings of Fedora RPM specs. 
> > Compiling R with the default setting of configure yields a version
> > that 
> > works for cluster... and nlme.
> > 
> >  I did not find the exact option that was the cause of this
> > issue 
> > but I'm willing to help.
> > 
> >  Erwan
> > 
> > PS: This is the reason why R is still at version 3.3.3 on the
> > Fedora 
> > distribution.
> > 
> > On 10/05/17 22:59, Langbehn, Douglas wrote:
> > > lme() and gls() models from the nlme package are all crashing
> > > with R.3.4.0. Identical code ran correctly, without error in R
> > > 3.3.3 and earlier versions.  The behavior is easily demonstrated
> > > using one of the examples form the lme() help file, along with
> > > two simple variants. I have commented the errors generated by
> > > these calls, as well as the lines of code generating them, in the
> > > code example below.
> > > 
> > > As of today, this bug had not been reported on the R Bugzilla
> > > page. I could not submit this report directly to the page because
> > > I am not a member, and , as explained in the "Reporting Bugs"
> > > link from the  R home page, membership has now been closed due to
> > > spamming problems..
> > > 
> > > #
> > > ###
> > > library(nlme)
> > > #Using version 3.1-131
> > > #Windows 7 64-bit operating system
> > > 
> > > fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~ 1)
> > > 
> > > # Error in array(c(rep(1, p), .C(inner_perc_table, as.double(X),
> > > as.integer(unlist(grps)),  :
> > > # object 'inner_perc_table' not found
> 
> That is a known issue with R 3.4.0 -- see NEWS.
> 
> Packages using .C and .Fortran _must_ be recompiled for R 3.4.0. If
> and when
> you do, the example will work again.
> 
> Dirk

However, the issue raised by Erwan on Fedora is a real bug which
affects at least two recommended packages. I know the cause of the
problem and am trying to find out how many packages are affected.

Martyn
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())

[William Dunlap via R-devel]

Here is a case where the current scheme fails:

  > with(datasets::mtcars, xyplot(mpg~wt|gear)$call)
  xyplot(substitute(expr), data, enclos = parent.frame())


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, May 11, 2017 at 1:09 AM, Deepayan Sarkar 
wrote:

> On Wed, May 10, 2017 at 2:36 AM, William Dunlap via R-devel
>  wrote:
> > Some formula methods for S3 generic functions use the idiom
> > returnValue$call <- sys.call(sys.parent())
> > to show how to recreate the returned object or to use as a label on a
> > plot.  It is often followed by
> >  returnValue$call[[1]] <- quote(myName)
> > E.g., I see it in packages "latticeExtra" and "leaps", and I suspect it
> > used in "lattice" as well.
> >
> > This idiom has not done good things for quite a while (ever?) but I
> noticed
> > while running tests that it acts differently in R-3.4.0 than in R-3.3.3.
> > Neither the old or new behavior is nice.  E.g., in R-3.3.3 we get
> >
> >> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
> >> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> > envir=new.env())
> > xyplot(expr, envir, enclos)
> >
> > and
> >
> >> evalInEnvir <- function(call, envir) eval(call, envir=envir)
> >> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> > envir=new.env())
> > xyplot(expr, envir, enclos)
> >
> > while in R-3.4.0 we get
> >> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
> >> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> > envir=new.env())
> > xyplot(parse(text = text), envir = envir)
> >
> > and
> >
> >> evalInEnvir <- function(call, envir) eval(call, envir=envir)
> >> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> > envir=new.env())
> > xyplot(call, envir = envir)
> >
> > Should these packages be be fixed up to use just sys.call()?
>
> I admit to not understanding these things very well, but I'll try to
> explain why I ended up with the usage I have. The main use of the
> $call component within lattice is to use it in the summary method, as
> in:
>
> > summary(xyplot(mpg~hp, data=mtcars))
>
> Call:
> xyplot(mpg ~ hp, data = mtcars)
>
> Number of observations:
> [1] 32
>
> Here is a minimal approximation to what I need: Here foo() and bar()
> are generics producing objects of class "foobar", bar() calls foo()
> with one argument changed, and the print() method for "foobar" is just
> supposed to print the call that produced it:
>
> 
>
> foo <- function(x, ...) UseMethod("foo")
> bar <- function(x, ...) UseMethod("bar")
> print.foobar <- function(x, ...) print(x$call)
>
> ## Using plain sys.call():
>
> foo.formula <- function(x, ...)
> {
> ans <- structure(list(), class = "foobar")
> ans$call <- sys.call()
> ans
> }
>
> bar.formula <- function(x, ..., panel)
> {
> foo.formula(x, ..., panel = panel.bar)
> }
>
> foo.table <- function(x, ...)
> {
> ans <- foo.formula(Freq ~ Var1,
>as.data.frame.table(x), ...)
> ans
> }
>
> ## I would get
>
> foo(y ~ x)
> # foo.formula(y ~ x)
>
> bar(y ~ x)
> # foo.formula(x, ..., panel = panel.bar)
>
> foo(as.table(1:10))
> # foo.formula(Freq ~ Var1, as.data.frame.table(x), ...)
>
> ## The last two are improved by
>
> foo.formula <- function(x, ...)
> {
> ans <- structure(list(), class = "foobar")
> ans$call <- sys.call(sys.parent())
> ans
> }
>
> bar(y ~ x)
> ## bar.formula(y ~ x)
>
> foo(as.table(1:10))
> ## foo.table(as.table(1:10))
>
> 
>
> Adding
>
> ans$call[[1]] <- quote(foo)
>
> (or quote(bar) in bar.formula) is needed to replace the unexported
> method name (foo.formula) with the generic name (foo), but that's
> probably not the problem.
>
> With this approach in lattice,
>
> p <- some.function(...)
> eval(p$call)
>
> usually works, but not always, if I remember correctly.
>
> I'm happy to consider more robust solutions. Maybe I just need to have a
>
> ...$call <- sys.call()
>
> statement in every method?
>
> -Deepayan
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] bug report: nlme model-fitting crashes with R 3.4.0

[Martyn Plummer]

On Thu, 2017-05-11 at 12:23 +, Martyn Plummer wrote:
> On Thu, 2017-05-11 at 06:37 -0500, Dirk Eddelbuettel wrote:
> > On 11 May 2017 at 10:17, Erwan Le Pennec wrote:
> > >  Dear all,
> > > 
> > >  I've stumbled a similar issue with the package cluster when 
> > > compiling the 3.4.0 version with the settings of Fedora RPM
> > > specs. 
> > > Compiling R with the default setting of configure yields a
> > > version
> > > that 
> > > works for cluster... and nlme.
> > > 
> > >  I did not find the exact option that was the cause of this
> > > issue 
> > > but I'm willing to help.
> > > 
> > >  Erwan
> > > 
> > > PS: This is the reason why R is still at version 3.3.3 on the
> > > Fedora 
> > > distribution.
> > > 
> > > On 10/05/17 22:59, Langbehn, Douglas wrote:
> > > > lme() and gls() models from the nlme package are all crashing
> > > > with R.3.4.0. Identical code ran correctly, without error in R
> > > > 3.3.3 and earlier versions.  The behavior is easily
> > > > demonstrated
> > > > using one of the examples form the lme() help file, along with
> > > > two simple variants. I have commented the errors generated by
> > > > these calls, as well as the lines of code generating them, in
> > > > the
> > > > code example below.
> > > > 
> > > > As of today, this bug had not been reported on the R Bugzilla
> > > > page. I could not submit this report directly to the page
> > > > because
> > > > I am not a member, and , as explained in the "Reporting Bugs"
> > > > link from the  R home page, membership has now been closed due
> > > > to
> > > > spamming problems..
> > > > 
> > > > ###
> > > > ##
> > > > ###
> > > > library(nlme)
> > > > #Using version 3.1-131
> > > > #Windows 7 64-bit operating system
> > > > 
> > > > fm2 <- lme(distance ~ age + Sex, data = Orthodont, random = ~
> > > > 1)
> > > > 
> > > > # Error in array(c(rep(1, p), .C(inner_perc_table,
> > > > as.double(X),
> > > > as.integer(unlist(grps)),  :
> > > > # object 'inner_perc_table' not found
> > 
> > That is a known issue with R 3.4.0 -- see NEWS.
> > 
> > Packages using .C and .Fortran _must_ be recompiled for R 3.4.0. If
> > and when
> > you do, the example will work again.
> > 
> > Dirk
> 
> However, the issue raised by Erwan on Fedora is a real bug which
> affects at least two recommended packages. I know the cause of the
> problem and am trying to find out how many packages are affected.

Sorry for the false alarm. Dirk is right and the problem is the binary
incompatibility between 3.4.0 and 3.3.3.

If you try building the R source RPM with R 3.4.0 *without using a
chroot* then you get interference from the installed version of R (i.e.
3.3.3) when the %check section of the spec file is run. This is not a
bug in the spec file because you are not supposed to build an SRPM this
way.

If you build the SRPM *using mock* (the chroot tool used by Red Hat)
then the build fails for a completely different reason. The chroot is
not set up with time zone information and this triggers one of the
regression tests.

I'm filing a bug report with Red Hat. So hopefully we will see RPMs of
R 3.4.0 for Fedora soon.

Martyn



> Martyn
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel