date:20180705

Re: [R-pkg-devel] compilation flags WARNING

2018-07-05 Thread Dirk Eddelbuettel



On 5 July 2018 at 22:19, Göran Broström wrote:
| Thanks Heather and Iñaki: I understand.
| 
| I have an old Makevars file in the src directory of the package.  I 
| guess I can set the flags there?

No, because those get scanned by R CMD check and friends.

For the one you do not want, Heather's suggestion was spot. Supply a new
(cleaner) system-wide default.  Those values are not checked.

I sometimes do the opposite and add (what would be "non-portable") options in
~/.R/Makevars to make very noisy builds quieter etc.

| Now it only contains
| 
| # PKG_CFLAGS = -Wall
| # PKG_FFLAGS = -Wall -fbounds-check
| PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

As we said no issues as nothing not allowed by R here.

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] compilation flags WARNING

2018-07-05 Thread Heather Turner

I would suggest not to set the CFLAGS in the package itself - at least not 
exclusively. R-admin 6.3.3 (the section I linked before) recommends "to  enable 
a reasonable amount of diagnostic messaging (“warnings”) when compiling, such 
as e.g. -Wall -pedantic for tools from GCC", while R-exts 1.2.1 says"When 
writing a Makevars file for a package you intend to distribute, take care to 
ensure that it is not specific to your compiler: flags such as -O2 -Wall 
-pedantic (and all other -W flags: for the Oracle compilers these are used to 
pass arguments to compiler phases) are all specific to GCC." Since these are 
contradictory, you can't satisfy both via PKG_CFLAGS alone. That is why I 
suggest to use the Makevars.site file to set pedantic flags for local use that 
are not distributed with the package (if you don't want to set them at a 
site-wide level R-admin 6.3.3 gives alternatives for setting at user-level).

Heather

On Thu, Jul 5, 2018, at 9:19 PM, Göran Broström wrote:
> Thanks Heather and Iñaki: I understand.
> 
> I have an old Makevars file in the src directory of the package.  I 
> guess I can set the flags there? Now it only contains
> 
> # PKG_CFLAGS = -Wall
> # PKG_FFLAGS = -Wall -fbounds-check
> PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
> 
> Göran
> 
> On 2018-07-05 17:43, Heather Turner wrote:
> > 
> > 
> > On Thu, Jul 5, 2018, at 3:39 PM, Iñaki Úcar wrote:
> >> El jue., 5 jul. 2018 a las 16:11, Göran Broström
> >> () escribió:
> >>>
> >>> I am preparing a CRAN release of eha (a trivial change due to a change
> >>> in the survival package), but when checking the build I get:
> >>>
> >>> goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
> >>> ...
> >>> * checking compilation flags used ... WARNING
> >>> Compilation used the following non-portable flag(s):
> >>> ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
> >>> ...
> >>
> >> AFAIK, these are new checks. I get similar warnings on Fedora for
> >> different flags.
> >>
> >>> I have never seen this before and I haven't (to my knowledge) set any
> >>> compilation flags. It is my first build and check on a newly upgraded
> >>> ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian,
> >>> or is that observation irrelevant?
> >>
> >> Again AFAIK (there are package maintainers for several distros here
> >> that can correct me if I'm wrong), each distro defines some policies
> >> regarding compilation flags that are applied to all packages by
> >> default. So these warnings can be safely ignored locally (or you may
> >> override them), because those flags won't be defined on CRAN.
> >>
> > Yes, by default the compilation flags are those set when R was installed. 
> > You can see the current flags via
> > 
> > R CMD config CFLAGS
> > 
> > which in your case should include  ‘-Wdate-time’ etc.
> > 
> > As Iñaki says you can safely ignore the warning, but if you prefer to not 
> > to have any warnings you can solve this by creating a Makevars.site file 
> > with CFLAGS excluding the non-portable ones, e.g.
> > 
> > CFLAGS=-Wall -g O0 -fPIC
> > 
> > This should be saved in the /etc directory of R.home(), e.g. /usr/lib/R/etc.
> > 
> > See 
> > https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> >  for more information.
> > 
> > Heather
> > 
> >> Iñaki
> >>
> >>>
> >>> Göran Broström
> >>
> >> __
> >> 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
> >
> 
> __
> 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

Re: [R-pkg-devel] compilation flags WARNING

2018-07-05 Thread Iñaki Úcar

El jue., 5 jul. 2018 a las 22:23, Göran Broström
() escribió:
>
> Thanks Heather and Iñaki: I understand.
>
> I have an old Makevars file in the src directory of the package.  I
> guess I can set the flags there? Now it only contains
>
> # PKG_CFLAGS = -Wall
> # PKG_FFLAGS = -Wall -fbounds-check
> PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

IMHO it's better to do it outside the package. The best way, without
changing the system settings, is to place a Makevars under ~/.R/

Iñaki

>
> Göran
>
> On 2018-07-05 17:43, Heather Turner wrote:
> >
> >
> > On Thu, Jul 5, 2018, at 3:39 PM, Iñaki Úcar wrote:
> >> El jue., 5 jul. 2018 a las 16:11, Göran Broström
> >> () escribió:
> >>>
> >>> I am preparing a CRAN release of eha (a trivial change due to a change
> >>> in the survival package), but when checking the build I get:
> >>>
> >>> goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
> >>> ...
> >>> * checking compilation flags used ... WARNING
> >>> Compilation used the following non-portable flag(s):
> >>> ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
> >>> ...
> >>
> >> AFAIK, these are new checks. I get similar warnings on Fedora for
> >> different flags.
> >>
> >>> I have never seen this before and I haven't (to my knowledge) set any
> >>> compilation flags. It is my first build and check on a newly upgraded
> >>> ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian,
> >>> or is that observation irrelevant?
> >>
> >> Again AFAIK (there are package maintainers for several distros here
> >> that can correct me if I'm wrong), each distro defines some policies
> >> regarding compilation flags that are applied to all packages by
> >> default. So these warnings can be safely ignored locally (or you may
> >> override them), because those flags won't be defined on CRAN.
> >>
> > Yes, by default the compilation flags are those set when R was installed. 
> > You can see the current flags via
> >
> > R CMD config CFLAGS
> >
> > which in your case should include  ‘-Wdate-time’ etc.
> >
> > As Iñaki says you can safely ignore the warning, but if you prefer to not 
> > to have any warnings you can solve this by creating a Makevars.site file 
> > with CFLAGS excluding the non-portable ones, e.g.
> >
> > CFLAGS=-Wall -g O0 -fPIC
> >
> > This should be saved in the /etc directory of R.home(), e.g. /usr/lib/R/etc.
> >
> > See 
> > https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> >  for more information.
> >
> > Heather
> >
> >> Iñaki
> >>
> >>>
> >>> Göran Broström
> >>
> >> __
> >> 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
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

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

Re: [R-pkg-devel] compilation flags WARNING

2018-07-05 Thread Göran Broström

Thanks Heather and Iñaki: I understand.

I have an old Makevars file in the src directory of the package. I
guess I can set the flags there? Now it only contains

# PKG_CFLAGS = -Wall
# PKG_FFLAGS = -Wall -fbounds-check
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

Göran

On 2018-07-05 17:43, Heather Turner wrote:

On Thu, Jul 5, 2018, at 3:39 PM, Iñaki Úcar wrote:

El jue., 5 jul. 2018 a las 16:11, Göran Broström
() escribió:

I am preparing a CRAN release of eha (a trivial change due to a change
in the survival package), but when checking the build I get:

goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
...
* checking compilation flags used ... WARNING
Compilation used the following non-portable flag(s):
‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
...

AFAIK, these are new checks. I get similar warnings on Fedora for
different flags.

I have never seen this before and I haven't (to my knowledge) set any
compilation flags. It is my first build and check on a newly upgraded
ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian,
or is that observation irrelevant?

Again AFAIK (there are package maintainers for several distros here
that can correct me if I'm wrong), each distro defines some policies
regarding compilation flags that are applied to all packages by
default. So these warnings can be safely ignored locally (or you may
override them), because those flags won't be defined on CRAN.

Yes, by default the compilation flags are those set when R was installed. You
can see the current flags via

R CMD config CFLAGS

which in your case should include ‘-Wdate-time’ etc.

As Iñaki says you can safely ignore the warning, but if you prefer to not to
have any warnings you can solve this by creating a Makevars.site file with
CFLAGS excluding the non-portable ones, e.g.

CFLAGS=-Wall -g O0 -fPIC

This should be saved in the /etc directory of R.home(), e.g. /usr/lib/R/etc.

See
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
for more information.

Heather

Iñaki

Göran Broström

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Iñaki Úcar

El jue., 5 jul. 2018 21:51, David Hugh-Jones 
escribió:

> That will indeed fail everywhere.  The puzzle is why it fails (only
> sometimes) when the methods are all exported. The GitHub equivalent is tag
> v4.0.1-rc1.
>

Yeap, but the point is that exporting the methods with 'export' should be
superfluous if S3method is used.


> On Thu, 5 Jul 2018 at 20:43, Iñaki Úcar  wrote:
>
>>
>>
>> El jue., 5 jul. 2018 21:35, David Hugh-Jones 
>> escribió:
>>
>>> Installed from CRAN or github? CRAN should be OK - I hope!
>>>
>>
>> From GitHub before the patch.
>>
>>
>>> On Thu, 5 Jul 2018 at 20:33, Iñaki Úcar  wrote:
>>>
 I installed huxtable in two environments, my own Fedora installation
 with R 3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4
 and an empty library. In both cases, huxtable is unusable: every example I
 try fails because it doesn't find the methods.

 So it has nothing to do with R checks or CRAN scripts, and it seems
 improbable to me that the error comes from a corrupted dependency.

 Iñaki


 El jue., 5 jul. 2018 20:06, Duncan Murdoch 
 escribió:

> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
> >
> > Agreed. I fixed the roxygen2 and it works fine. But yet, the
> original
> > v4.0.1 on CRAN has a namespace file which contains
> >
> > S3method(bold,huxtable)
> > export(bold)
> > export(bold.huxtable)
> >
> > and
> >
> > S3method("align<-",huxtable)
> > export("align<-")
> > export("align<-.huxtable")
> >
> > yet still fails on linux-patched and linux-release, with "no
> applicable
> > method" errors for align<- and bold. Unfortunately, I don't know how
> to
> > reproduce the error on any other platform
>
> I just got R installed on an Ubuntu VM, and ran "R CMD check
> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without
> seeing
> the error you quoted.  (I did see other problems, related to not
> having
> things like pandoc installed; nothing that looked like a problem with
> the package rather than a problem with my R installation.)
>
> That looks like a bug, but without having a system that can reproduce
> it, it's hard to narrow down where:
>
>   - In R's checks?  Seems unlikely, given it is so system specific.
>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>   - In huxtable or some package used by huxtable?  Seems possible:
> maybe memory got corrupted.  Perhaps running under some memory checker
> would be more informative.
>
> Perhaps the CRAN team could be helpful here.
>
> >
> > Anyway, meanwhile, my problem is fixed and I have learned something
> > about function environments.
>
> Given that the error is unrelated to the solution, it really looks
> like
> memory corruption somewhere or other.
>
> Duncan Murdoch
>
 --
>>> Sent from Gmail Mobile
>>>
>> --
> Sent from Gmail Mobile
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread David Hugh-Jones

That will indeed fail everywhere.  The puzzle is why it fails (only
sometimes) when the methods are all exported. The GitHub equivalent is tag
v4.0.1-rc1.

On Thu, 5 Jul 2018 at 20:43, Iñaki Úcar  wrote:

>
>
> El jue., 5 jul. 2018 21:35, David Hugh-Jones 
> escribió:
>
>> Installed from CRAN or github? CRAN should be OK - I hope!
>>
>
> From GitHub before the patch.
>
>
>> On Thu, 5 Jul 2018 at 20:33, Iñaki Úcar  wrote:
>>
>>> I installed huxtable in two environments, my own Fedora installation
>>> with R 3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4
>>> and an empty library. In both cases, huxtable is unusable: every example I
>>> try fails because it doesn't find the methods.
>>>
>>> So it has nothing to do with R checks or CRAN scripts, and it seems
>>> improbable to me that the error comes from a corrupted dependency.
>>>
>>> Iñaki
>>>
>>>
>>> El jue., 5 jul. 2018 20:06, Duncan Murdoch 
>>> escribió:
>>>
 On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
 >
 > Agreed. I fixed the roxygen2 and it works fine. But yet, the original
 > v4.0.1 on CRAN has a namespace file which contains
 >
 > S3method(bold,huxtable)
 > export(bold)
 > export(bold.huxtable)
 >
 > and
 >
 > S3method("align<-",huxtable)
 > export("align<-")
 > export("align<-.huxtable")
 >
 > yet still fails on linux-patched and linux-release, with "no
 applicable
 > method" errors for align<- and bold. Unfortunately, I don't know how
 to
 > reproduce the error on any other platform

 I just got R installed on an Ubuntu VM, and ran "R CMD check
 huxtable_4.0.1.tar.gz" both with and without "--as-cran", without
 seeing
 the error you quoted.  (I did see other problems, related to not having
 things like pandoc installed; nothing that looked like a problem with
 the package rather than a problem with my R installation.)

 That looks like a bug, but without having a system that can reproduce
 it, it's hard to narrow down where:

   - In R's checks?  Seems unlikely, given it is so system specific.
   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
   - In huxtable or some package used by huxtable?  Seems possible:
 maybe memory got corrupted.  Perhaps running under some memory checker
 would be more informative.

 Perhaps the CRAN team could be helpful here.

 >
 > Anyway, meanwhile, my problem is fixed and I have learned something
 > about function environments.

 Given that the error is unrelated to the solution, it really looks like
 memory corruption somewhere or other.

 Duncan Murdoch

>>> --
>> Sent from Gmail Mobile
>>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread David Hugh-Jones

Installed from CRAN or github? CRAN should be OK - I hope!

On Thu, 5 Jul 2018 at 20:33, Iñaki Úcar  wrote:

> I installed huxtable in two environments, my own Fedora installation with
> R 3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4 and
> an empty library. In both cases, huxtable is unusable: every example I try
> fails because it doesn't find the methods.
>
> So it has nothing to do with R checks or CRAN scripts, and it seems
> improbable to me that the error comes from a corrupted dependency.
>
> Iñaki
>
>
> El jue., 5 jul. 2018 20:06, Duncan Murdoch 
> escribió:
>
>> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
>> >
>> > Agreed. I fixed the roxygen2 and it works fine. But yet, the original
>> > v4.0.1 on CRAN has a namespace file which contains
>> >
>> > S3method(bold,huxtable)
>> > export(bold)
>> > export(bold.huxtable)
>> >
>> > and
>> >
>> > S3method("align<-",huxtable)
>> > export("align<-")
>> > export("align<-.huxtable")
>> >
>> > yet still fails on linux-patched and linux-release, with "no applicable
>> > method" errors for align<- and bold. Unfortunately, I don't know how to
>> > reproduce the error on any other platform
>>
>> I just got R installed on an Ubuntu VM, and ran "R CMD check
>> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without seeing
>> the error you quoted.  (I did see other problems, related to not having
>> things like pandoc installed; nothing that looked like a problem with
>> the package rather than a problem with my R installation.)
>>
>> That looks like a bug, but without having a system that can reproduce
>> it, it's hard to narrow down where:
>>
>>   - In R's checks?  Seems unlikely, given it is so system specific.
>>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>>   - In huxtable or some package used by huxtable?  Seems possible:
>> maybe memory got corrupted.  Perhaps running under some memory checker
>> would be more informative.
>>
>> Perhaps the CRAN team could be helpful here.
>>
>> >
>> > Anyway, meanwhile, my problem is fixed and I have learned something
>> > about function environments.
>>
>> Given that the error is unrelated to the solution, it really looks like
>> memory corruption somewhere or other.
>>
>> Duncan Murdoch
>>
> --
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Iñaki Úcar

El jue., 5 jul. 2018 21:35, David Hugh-Jones 
escribió:

> Installed from CRAN or github? CRAN should be OK - I hope!
>

>From GitHub before the patch.


> On Thu, 5 Jul 2018 at 20:33, Iñaki Úcar  wrote:
>
>> I installed huxtable in two environments, my own Fedora installation with
>> R 3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4 and
>> an empty library. In both cases, huxtable is unusable: every example I try
>> fails because it doesn't find the methods.
>>
>> So it has nothing to do with R checks or CRAN scripts, and it seems
>> improbable to me that the error comes from a corrupted dependency.
>>
>> Iñaki
>>
>>
>> El jue., 5 jul. 2018 20:06, Duncan Murdoch 
>> escribió:
>>
>>> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
>>> >
>>> > Agreed. I fixed the roxygen2 and it works fine. But yet, the original
>>> > v4.0.1 on CRAN has a namespace file which contains
>>> >
>>> > S3method(bold,huxtable)
>>> > export(bold)
>>> > export(bold.huxtable)
>>> >
>>> > and
>>> >
>>> > S3method("align<-",huxtable)
>>> > export("align<-")
>>> > export("align<-.huxtable")
>>> >
>>> > yet still fails on linux-patched and linux-release, with "no
>>> applicable
>>> > method" errors for align<- and bold. Unfortunately, I don't know how
>>> to
>>> > reproduce the error on any other platform
>>>
>>> I just got R installed on an Ubuntu VM, and ran "R CMD check
>>> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without seeing
>>> the error you quoted.  (I did see other problems, related to not having
>>> things like pandoc installed; nothing that looked like a problem with
>>> the package rather than a problem with my R installation.)
>>>
>>> That looks like a bug, but without having a system that can reproduce
>>> it, it's hard to narrow down where:
>>>
>>>   - In R's checks?  Seems unlikely, given it is so system specific.
>>>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>>>   - In huxtable or some package used by huxtable?  Seems possible:
>>> maybe memory got corrupted.  Perhaps running under some memory checker
>>> would be more informative.
>>>
>>> Perhaps the CRAN team could be helpful here.
>>>
>>> >
>>> > Anyway, meanwhile, my problem is fixed and I have learned something
>>> > about function environments.
>>>
>>> Given that the error is unrelated to the solution, it really looks like
>>> memory corruption somewhere or other.
>>>
>>> Duncan Murdoch
>>>
>> --
> Sent from Gmail Mobile
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Iñaki Úcar

I installed huxtable in two environments, my own Fedora installation with R
3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4 and an
empty library. In both cases, huxtable is unusable: every example I try
fails because it doesn't find the methods.

So it has nothing to do with R checks or CRAN scripts, and it seems
improbable to me that the error comes from a corrupted dependency.

Iñaki

El jue., 5 jul. 2018 20:06, Duncan Murdoch 
escribió:

> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
> >
> > Agreed. I fixed the roxygen2 and it works fine. But yet, the original
> > v4.0.1 on CRAN has a namespace file which contains
> >
> > S3method(bold,huxtable)
> > export(bold)
> > export(bold.huxtable)
> >
> > and
> >
> > S3method("align<-",huxtable)
> > export("align<-")
> > export("align<-.huxtable")
> >
> > yet still fails on linux-patched and linux-release, with "no applicable
> > method" errors for align<- and bold. Unfortunately, I don't know how to
> > reproduce the error on any other platform
>
> I just got R installed on an Ubuntu VM, and ran "R CMD check
> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without seeing
> the error you quoted.  (I did see other problems, related to not having
> things like pandoc installed; nothing that looked like a problem with
> the package rather than a problem with my R installation.)
>
> That looks like a bug, but without having a system that can reproduce
> it, it's hard to narrow down where:
>
>   - In R's checks?  Seems unlikely, given it is so system specific.
>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>   - In huxtable or some package used by huxtable?  Seems possible:
> maybe memory got corrupted.  Perhaps running under some memory checker
> would be more informative.
>
> Perhaps the CRAN team could be helpful here.
>
> >
> > Anyway, meanwhile, my problem is fixed and I have learned something
> > about function environments.
>
> Given that the error is unrelated to the solution, it really looks like
> memory corruption somewhere or other.
>
> Duncan Murdoch
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Duncan Murdoch


On 05/07/2018 2:06 PM, Duncan Murdoch wrote:

On 05/07/2018 9:11 AM, David Hugh-Jones wrote:


Agreed. I fixed the roxygen2 and it works fine. But yet, the original
v4.0.1 on CRAN has a namespace file which contains

S3method(bold,huxtable)
export(bold)
export(bold.huxtable)

and

S3method("align<-",huxtable)
export("align<-")
export("align<-.huxtable")

yet still fails on linux-patched and linux-release, with "no applicable
method" errors for align<- and bold. Unfortunately, I don't know how to
reproduce the error on any other platform


I just got R installed on an Ubuntu VM, and ran "R CMD check
huxtable_4.0.1.tar.gz" both with and without "--as-cran", without seeing
the error you quoted.  (I did see other problems, related to not having
things like pandoc installed; nothing that looked like a problem with
the package rather than a problem with my R installation.)

That looks like a bug, but without having a system that can reproduce
it, it's hard to narrow down where:

   - In R's checks?  Seems unlikely, given it is so system specific.
   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
   - In huxtable or some package used by huxtable?  Seems possible:
maybe memory got corrupted.  Perhaps running under some memory checker
would be more informative.


I just tried valgrind on Ubuntu and it didn't see anything.

Duncan Murdoch



Perhaps the CRAN team could be helpful here.



Anyway, meanwhile, my problem is fixed and I have learned something
about function environments.


Given that the error is unrelated to the solution, it really looks like
memory corruption somewhere or other.

Duncan Murdoch



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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Duncan Murdoch


On 05/07/2018 9:11 AM, David Hugh-Jones wrote:


Agreed. I fixed the roxygen2 and it works fine. But yet, the original 
v4.0.1 on CRAN has a namespace file which contains


S3method(bold,huxtable)
export(bold)
export(bold.huxtable)

and

S3method("align<-",huxtable)
export("align<-")
export("align<-.huxtable")

yet still fails on linux-patched and linux-release, with "no applicable 
method" errors for align<- and bold. Unfortunately, I don't know how to 
reproduce the error on any other platform


I just got R installed on an Ubuntu VM, and ran "R CMD check 
huxtable_4.0.1.tar.gz" both with and without "--as-cran", without seeing 
the error you quoted.  (I did see other problems, related to not having 
things like pandoc installed; nothing that looked like a problem with 
the package rather than a problem with my R installation.)


That looks like a bug, but without having a system that can reproduce 
it, it's hard to narrow down where:


 - In R's checks?  Seems unlikely, given it is so system specific.
 - In CRAN's scripts?  Really unlikely, since all the tests are in R.
 - In huxtable or some package used by huxtable?  Seems possible: 
maybe memory got corrupted.  Perhaps running under some memory checker 
would be more informative.


Perhaps the CRAN team could be helpful here.



Anyway, meanwhile, my problem is fixed and I have learned something 
about function environments.


Given that the error is unrelated to the solution, it really looks like 
memory corruption somewhere or other.


Duncan Murdoch

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

Re: [R-pkg-devel] compilation flags WARNING

2018-07-05 Thread Heather Turner




On Thu, Jul 5, 2018, at 3:39 PM, Iñaki Úcar wrote:
> El jue., 5 jul. 2018 a las 16:11, Göran Broström
> () escribió:
> >
> > I am preparing a CRAN release of eha (a trivial change due to a change
> > in the survival package), but when checking the build I get:
> >
> > goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
> > ...
> > * checking compilation flags used ... WARNING
> > Compilation used the following non-portable flag(s):
> >‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
> > ...
> 
> AFAIK, these are new checks. I get similar warnings on Fedora for
> different flags.
> 
> > I have never seen this before and I haven't (to my knowledge) set any
> > compilation flags. It is my first build and check on a newly upgraded
> > ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian,
> > or is that observation irrelevant?
> 
> Again AFAIK (there are package maintainers for several distros here
> that can correct me if I'm wrong), each distro defines some policies
> regarding compilation flags that are applied to all packages by
> default. So these warnings can be safely ignored locally (or you may
> override them), because those flags won't be defined on CRAN.
> 
Yes, by default the compilation flags are those set when R was installed. You 
can see the current flags via

R CMD config CFLAGS

which in your case should include  ‘-Wdate-time’ etc.

As Iñaki says you can safely ignore the warning, but if you prefer to not to 
have any warnings you can solve this by creating a Makevars.site file with 
CFLAGS excluding the non-portable ones, e.g.

CFLAGS=-Wall -g O0 -fPIC

This should be saved in the /etc directory of R.home(), e.g. /usr/lib/R/etc.

See 
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
 for more information.

Heather

> Iñaki
> 
> >
> > Göran Broström
> 
> __
> 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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Joris Meys

For the record: I've checked this in R 3.5.0 and R 3.4.4, and in both cases
this problem exists.

Also, I need to correct myself: The correct way to document with roxygen is
to use _both_ the @method and @export tag:

@method foo bar
@export

That registers the S3 method correctly (and hence doesn't export the method
itself).

On Thu, Jul 5, 2018 at 4:18 PM, Joris Meys  wrote:

> I see that you realized it was Inaki who gave you he patch, not me :-)
>
> I've been looking into this further, and the toy example David put up is
> actually not the right one to look at. In that example the generic is
> created in the namespace.  But in the original huxtable that was not the
> case. Try the following :
>
> foo.barrista <- function(x, ...){
>   cat("In barrista\n")
> }
>
> make_a_method <- function (x){
>   assign("foo", function(x, ...){
> UseMethod("foo")
>   } ,envir = getNamespace('testMethod'))
>
>   assign("foo.bar", function (x, ...) cat("In foo.bar"),
>  envir = getNamespace('testMethod'))
> }
> make_a_method()
>
> With a namespace:
>
> S3method(foo,bar)
> S3method(foo,barrista)
> export(foo)
>
> And test code :
>
> thebar <- structure(1, class = c("bar", "data.frame"))
> thebarrista <- structure(1, class = "barrista")
>
> foo(thebarrista)
> foo(thebar)
>
> In both cases the correct method cannot be found. When the methods are
> both exported and registered (i.e. add export(foo.bar) and
> export(foo.barrista) to NAMESPACE), everything goes fine again on Windows.I
> went back to the original version you sent to CRAN, and that doesn't cause
> any problems on Windows either. So when the methods are exported and
> registered, the problem apparently only exists on Linux.
>
> The other thing I've noticed, is that align() is called from within the
> function huxtable() without problem. So the method is found when the
> generic is called by a function in the namespace, but not when the generic
> is called from the global env. The patch of Inaki makes sure that the
> _generic_ is assigned in the namespace itself instead of a child
> environment.
>
> To the previous minimal example, add:
>
> baz <- function(x) foo(x)
>
> and to the NAMESPACE:
>
> export(baz)
>
> If you try now:
>
> baz(thebar)
> baz(thebarrista)
>
> the correct methods are found. But foo(thebar) etc still doesn't find the
> correct ones.
>
> On a sidenote: roxygen is really not helping here. @export literally
> exports all these methods as they're not recognized as S3methods. So here
> you actually need the deprecated tag @S3method. I wish Hadley would revert
> the deprecation, as @export fails to recognize S3 methods correctly in
> other cases as well.
>
>
> On Thu, Jul 5, 2018 at 1:19 PM, Duncan Murdoch 
> wrote:
>
>> On 05/07/2018 5:22 AM, David Hugh-Jones wrote:
>>
>>>
>>> Wow, this is extremely helpful. I've applied Joris' patch. By the way,
>>> the github master has the change that I stopped exporting methods, as per
>>> Hadley's suggestion; this caused *all* functions created via
>>> make_getter_setters to fail. Version 4.0.1 on CRAN has the methods
>>> exported, which was masking the error in most cases. I don't know why
>>> bold() was failing in certain cases only... in any case, the patch seems to
>>> fix things.
>>>
>>>
>> That's a roxygen2 bug or misuse.  If you use the code below without the
>> roxygen2 processing, and manually build the NAMESPACE file as
>>
>> export(foo)
>> S3method(foo, bar)
>>
>> then things are fine.  I don't know roxygen2 well enough to know what
>> else you should have done to get your NAMESPACE file to look like that.
>>
>> Duncan Murdoch
>>
>>
>> Here is a brief test case that shows the original problem. I don't know
>>> whether this reveals any problem in base R:
>>>
>>> # in package mypackage:
>>> #' @export
>>> foo <- function (x, ...) UseMethod('foo')
>>> make_a_method <- function () assign("foo.bar", function (x, ...) cat("In
>>> foo.bar"), pos = getNamespace('mypackage'))
>>> make_a_method()
>>>
>>> # in the console:
>>> library(mypackage)
>>> mypackage:::foo.bar
>>> ## function (x, ...) cat("In foo.bar")
>>> ## 
>>> ## 
>>> x <- structure(1, class='bar')
>>> foo(x)
>>> ## Error in UseMethod("foo") :
>>> ##  no applicable method for 'foo' applied to an object of class "bar"
>>>
>>> Also, I know I shouldn't be using @s3method ... it's on the TODO list...
>>> !
>>>
>>> Cheers,
>>> David
>>>
>>>
>>> On Thu, 5 Jul 2018 at 09:07, Iñaki Úcar >> i.uca...@gmail.com>> wrote:
>>>
>>> El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
>>> (mailto:murdoch.dun...@gmail.com>>)
>>> escribió:
>>>  >
>>>  > On 04/07/2018 4:04 PM, Joris Meys wrote:
>>>  > >
>>>  > >
>>>  > > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch
>>> mailto:murdoch.dun...@gmail.com>
>>>  > > >>
>>> >> wrote:
>>>  > >
>>>  > >
>>>  > > That shouldn't matter.  That function was created in a local
>>>  > > envir

Re: [R-pkg-devel] compilation flags WARNING

2018-07-05 Thread Iñaki Úcar

El jue., 5 jul. 2018 a las 16:11, Göran Broström
() escribió:
>
> I am preparing a CRAN release of eha (a trivial change due to a change
> in the survival package), but when checking the build I get:
>
> goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
> ...
> * checking compilation flags used ... WARNING
> Compilation used the following non-portable flag(s):
>‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
> ...

AFAIK, these are new checks. I get similar warnings on Fedora for
different flags.

> I have never seen this before and I haven't (to my knowledge) set any
> compilation flags. It is my first build and check on a newly upgraded
> ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian,
> or is that observation irrelevant?

Again AFAIK (there are package maintainers for several distros here
that can correct me if I'm wrong), each distro defines some policies
regarding compilation flags that are applied to all packages by
default. So these warnings can be safely ignored locally (or you may
override them), because those flags won't be defined on CRAN.

Iñaki

>
> Göran Broström

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Joris Meys

I see that you realized it was Inaki who gave you he patch, not me :-)

I've been looking into this further, and the toy example David put up is
actually not the right one to look at. In that example the generic is
created in the namespace.  But in the original huxtable that was not the
case. Try the following :

foo.barrista <- function(x, ...){
  cat("In barrista\n")
}

make_a_method <- function (x){
  assign("foo", function(x, ...){
UseMethod("foo")
  } ,envir = getNamespace('testMethod'))

  assign("foo.bar", function (x, ...) cat("In foo.bar"),
 envir = getNamespace('testMethod'))
}
make_a_method()

With a namespace:

S3method(foo,bar)
S3method(foo,barrista)
export(foo)

And test code :

thebar <- structure(1, class = c("bar", "data.frame"))
thebarrista <- structure(1, class = "barrista")

foo(thebarrista)
foo(thebar)

In both cases the correct method cannot be found. When the methods are both
exported and registered (i.e. add export(foo.bar) and export(foo.barrista)
to NAMESPACE), everything goes fine again on Windows.I went back to the
original version you sent to CRAN, and that doesn't cause any problems on
Windows either. So when the methods are exported and registered, the
problem apparently only exists on Linux.

The other thing I've noticed, is that align() is called from within the
function huxtable() without problem. So the method is found when the
generic is called by a function in the namespace, but not when the generic
is called from the global env. The patch of Inaki makes sure that the
_generic_ is assigned in the namespace itself instead of a child
environment.

To the previous minimal example, add:

baz <- function(x) foo(x)

and to the NAMESPACE:

export(baz)

If you try now:

baz(thebar)
baz(thebarrista)

the correct methods are found. But foo(thebar) etc still doesn't find the
correct ones.

On a sidenote: roxygen is really not helping here. @export literally
exports all these methods as they're not recognized as S3methods. So here
you actually need the deprecated tag @S3method. I wish Hadley would revert
the deprecation, as @export fails to recognize S3 methods correctly in
other cases as well.

On Thu, Jul 5, 2018 at 1:19 PM, Duncan Murdoch 
wrote:

> On 05/07/2018 5:22 AM, David Hugh-Jones wrote:
>
>>
>> Wow, this is extremely helpful. I've applied Joris' patch. By the way,
>> the github master has the change that I stopped exporting methods, as per
>> Hadley's suggestion; this caused *all* functions created via
>> make_getter_setters to fail. Version 4.0.1 on CRAN has the methods
>> exported, which was masking the error in most cases. I don't know why
>> bold() was failing in certain cases only... in any case, the patch seems to
>> fix things.
>>
>>
> That's a roxygen2 bug or misuse.  If you use the code below without the
> roxygen2 processing, and manually build the NAMESPACE file as
>
> export(foo)
> S3method(foo, bar)
>
> then things are fine.  I don't know roxygen2 well enough to know what else
> you should have done to get your NAMESPACE file to look like that.
>
> Duncan Murdoch
>
>
> Here is a brief test case that shows the original problem. I don't know
>> whether this reveals any problem in base R:
>>
>> # in package mypackage:
>> #' @export
>> foo <- function (x, ...) UseMethod('foo')
>> make_a_method <- function () assign("foo.bar", function (x, ...) cat("In
>> foo.bar"), pos = getNamespace('mypackage'))
>> make_a_method()
>>
>> # in the console:
>> library(mypackage)
>> mypackage:::foo.bar
>> ## function (x, ...) cat("In foo.bar")
>> ## 
>> ## 
>> x <- structure(1, class='bar')
>> foo(x)
>> ## Error in UseMethod("foo") :
>> ##  no applicable method for 'foo' applied to an object of class "bar"
>>
>> Also, I know I shouldn't be using @s3method ... it's on the TODO list... !
>>
>> Cheers,
>> David
>>
>>
>> On Thu, 5 Jul 2018 at 09:07, Iñaki Úcar > i.uca...@gmail.com>> wrote:
>>
>> El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
>> (mailto:murdoch.dun...@gmail.com>>)
>> escribió:
>>  >
>>  > On 04/07/2018 4:04 PM, Joris Meys wrote:
>>  > >
>>  > >
>>  > > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch
>> mailto:murdoch.dun...@gmail.com>
>>  > > >
>> >> wrote:
>>  > >
>>  > >
>>  > > That shouldn't matter.  That function was created in a local
>>  > > environment whose parent is 
>>  > > (probably by the huxtable:::make_setter_getters function,
>> but I
>>  > > didn't check).
>>  > >
>>  > > Duncan Murdoch
>>  > >
>>  > > I would think it does matter. Methods are found on the search
>> path, but
>>  > > the environment where the methods are defined is not on the
>> search path.
>>  > > It's a child environment of the namespace, and hence cannot be
>> reached
>>  > > from either the global environment or the namespace if I
>> understood it
>>  > > correctly.
>>

[R-pkg-devel] compilation flags WARNING

2018-07-05 Thread Göran Broström

I am preparing a CRAN release of eha (a trivial change due to a change 
in the survival package), but when checking the build I get:


goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
...
* checking compilation flags used ... WARNING
Compilation used the following non-portable flag(s):
  ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
...

I have never seen this before and I haven't (to my knowledge) set any 
compilation flags. It is my first build and check on a newly upgraded 
ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian, 
or is that observation irrelevant?


Göran Broström

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread David Hugh-Jones

Agreed. I fixed the roxygen2 and it works fine. But yet, the original
v4.0.1 on CRAN has a namespace file which contains

S3method(bold,huxtable)
export(bold)
export(bold.huxtable)

and

S3method("align<-",huxtable)
export("align<-")
export("align<-.huxtable")

yet still fails on linux-patched and linux-release, with "no applicable
method" errors for align<- and bold. Unfortunately, I don't know how to
reproduce the error on any other platform

Anyway, meanwhile, my problem is fixed and I have learned something about
function environments.

Cheers,
David

On Thu, 5 Jul 2018 at 12:20, Duncan Murdoch 
wrote:

>
> That's a roxygen2 bug or misuse.  If you use the code below without the
> roxygen2 processing, and manually build the NAMESPACE file as
>
> export(foo)
> S3method(foo, bar)
>
> then things are fine.  I don't know roxygen2 well enough to know what
> else you should have done to get your NAMESPACE file to look like that.
>
> Duncan Murdoch
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Duncan Murdoch

On 05/07/2018 5:22 AM, David Hugh-Jones wrote:

Wow, this is extremely helpful. I've applied Joris' patch. By the way, 
the github master has the change that I stopped exporting methods, as 
per Hadley's suggestion; this caused *all* functions created via 
make_getter_setters to fail. Version 4.0.1 on CRAN has the methods 
exported, which was masking the error in most cases. I don't know why 
bold() was failing in certain cases only... in any case, the patch seems 
to fix things.

That's a roxygen2 bug or misuse.  If you use the code below without the 
roxygen2 processing, and manually build the NAMESPACE file as

export(foo)
S3method(foo, bar)

then things are fine.  I don't know roxygen2 well enough to know what 
else you should have done to get your NAMESPACE file to look like that.

Duncan Murdoch

Here is a brief test case that shows the original problem. I don't know 
whether this reveals any problem in base R:

# in package mypackage:
#' @export
foo <- function (x, ...) UseMethod('foo')
make_a_method <- function () assign("foo.bar", function (x, ...) cat("In 
foo.bar"), pos = getNamespace('mypackage'))

make_a_method()

# in the console:
library(mypackage)
mypackage:::foo.bar
## function (x, ...) cat("In foo.bar")
## 
## 
x <- structure(1, class='bar')
foo(x)
## Error in UseMethod("foo") :
##  no applicable method for 'foo' applied to an object of class "bar"

Also, I know I shouldn't be using @s3method ... it's on the TODO list... !

Cheers,
David

On Thu, 5 Jul 2018 at 09:07, Iñaki Úcar > wrote:

El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
(mailto:murdoch.dun...@gmail.com>>) escribió:
 >
 > On 04/07/2018 4:04 PM, Joris Meys wrote:
 > >
 > >
 > > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch
mailto:murdoch.dun...@gmail.com>
 > > >> wrote:
 > >
 > >
 > >     That shouldn't matter.  That function was created in a local
 > >     environment whose parent is 
 > >     (probably by the huxtable:::make_setter_getters function, but I
 > >     didn't check).
 > >
 > >     Duncan Murdoch
 > >
 > > I would think it does matter. Methods are found on the search
path, but
 > > the environment where the methods are defined is not on the
search path.
 > > It's a child environment of the namespace, and hence cannot be
reached
 > > from either the global environment or the namespace if I
understood it
 > > correctly.
 > >
 >
 > The environment of a function is where it looks for objects, not
where
 > it is stored.  That method is stored in the huxtable namespace, and
 > exported from it.  That's why
 > getFromNamespace("align.huxtable","huxtable") (or even
 > huxtable::align.huxtable) finds it.
 >
 > I don't know the source of the original error.

I don't know either. But obviously it has something to do with the
function environment and how UseMethod looks for methods when they are
exported from a namespace (I tested a similar "layout" in the global
environment and the method is correctly found). So maybe this thread
belongs to r-devel instead.

Iñaki

 >
 > Duncan Murdoch
 >

__
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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread David Hugh-Jones

Wow, this is extremely helpful. I've applied Joris' patch. By the way, the
github master has the change that I stopped exporting methods, as per
Hadley's suggestion; this caused *all* functions created via
make_getter_setters to fail. Version 4.0.1 on CRAN has the methods
exported, which was masking the error in most cases. I don't know why
bold() was failing in certain cases only... in any case, the patch seems to
fix things.

Here is a brief test case that shows the original problem. I don't know
whether this reveals any problem in base R:

# in package mypackage:
#' @export
foo <- function (x, ...) UseMethod('foo')
make_a_method <- function () assign("foo.bar", function (x, ...) cat("In
foo.bar"), pos = getNamespace('mypackage'))
make_a_method()

# in the console:
library(mypackage)
mypackage:::foo.bar
## function (x, ...) cat("In foo.bar")
## 
## 
x <- structure(1, class='bar')
foo(x)
## Error in UseMethod("foo") :
##  no applicable method for 'foo' applied to an object of class "bar"

Also, I know I shouldn't be using @s3method ... it's on the TODO list... !

Cheers,
David


On Thu, 5 Jul 2018 at 09:07, Iñaki Úcar  wrote:

> El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
> () escribió:
> >
> > On 04/07/2018 4:04 PM, Joris Meys wrote:
> > >
> > >
> > > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch <
> murdoch.dun...@gmail.com
> > > > wrote:
> > >
> > >
> > > That shouldn't matter.  That function was created in a local
> > > environment whose parent is 
> > > (probably by the huxtable:::make_setter_getters function, but I
> > > didn't check).
> > >
> > > Duncan Murdoch
> > >
> > > I would think it does matter. Methods are found on the search path, but
> > > the environment where the methods are defined is not on the search
> path.
> > > It's a child environment of the namespace, and hence cannot be reached
> > > from either the global environment or the namespace if I understood it
> > > correctly.
> > >
> >
> > The environment of a function is where it looks for objects, not where
> > it is stored.  That method is stored in the huxtable namespace, and
> > exported from it.  That's why
> > getFromNamespace("align.huxtable","huxtable") (or even
> > huxtable::align.huxtable) finds it.
> >
> > I don't know the source of the original error.
>
> I don't know either. But obviously it has something to do with the
> function environment and how UseMethod looks for methods when they are
> exported from a namespace (I tested a similar "layout" in the global
> environment and the method is correctly found). So maybe this thread
> belongs to r-devel instead.
>
> Iñaki
>
> >
> > Duncan Murdoch
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

2018-07-05 Thread Iñaki Úcar

El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
() escribió:
>
> On 04/07/2018 4:04 PM, Joris Meys wrote:
> >
> >
> > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch  > > wrote:
> >
> >
> > That shouldn't matter.  That function was created in a local
> > environment whose parent is 
> > (probably by the huxtable:::make_setter_getters function, but I
> > didn't check).
> >
> > Duncan Murdoch
> >
> > I would think it does matter. Methods are found on the search path, but
> > the environment where the methods are defined is not on the search path.
> > It's a child environment of the namespace, and hence cannot be reached
> > from either the global environment or the namespace if I understood it
> > correctly.
> >
>
> The environment of a function is where it looks for objects, not where
> it is stored.  That method is stored in the huxtable namespace, and
> exported from it.  That's why
> getFromNamespace("align.huxtable","huxtable") (or even
> huxtable::align.huxtable) finds it.
>
> I don't know the source of the original error.

I don't know either. But obviously it has something to do with the
function environment and how UseMethod looks for methods when they are
exported from a namespace (I tested a similar "layout" in the global
environment and the method is correctly found). So maybe this thread
belongs to r-devel instead.

Iñaki

>
> Duncan Murdoch
>

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

Re: [R-pkg-devel] compilation flags WARNING

Re: [R-pkg-devel] compilation flags WARNING

Re: [R-pkg-devel] compilation flags WARNING

Re: [R-pkg-devel] compilation flags WARNING

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] compilation flags WARNING

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] compilation flags WARNING

Re: [R-pkg-devel] Weird error on CRAN linux check

[R-pkg-devel] compilation flags WARNING

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

Re: [R-pkg-devel] Weird error on CRAN linux check

20 matches

Site Navigation

Mail list logo

Footer information