Re: [Rd] New behavior when running script in package directory?

[Mikael Jagan]

Surely this behaviour is just a case of ESS being "too clever", sourcing
*.R files in special way when it detects that a file belongs to a package
(loading dependencies automatically, etc.)?

The function ss() is defined inside of .ess.source(), which is defined here:

https://github.com/emacs-ess/ESS/blob/5c4ae91cefa5c56fd13b204a9a996825af836a67/etc/ESSR/R/.basic.R#L168

If you think that there is a bug, then you could report it there ...

Mikael

On 2023-06-21 6:00 am, r-devel-requ...@r-project.org wrote:

When I run a script foo.R containing some trivial code in my home
directory, via Emacs/ESS, everything works as expected: R
starts, and a setwd() command to set the working directory is
run automatically before the code in the script is run.

But if I copy foo.R to some package/R directory strange
things happen. When I use Emacs/ESS to run the script
in its new location, R starts, and setwd() is called to set
the working directory, but then one or more libraries that the
package depends on are loaded, even though I am using no
libraries in foo.R.

Now consider foo.R that contains the following trivial code:
secsToRDateTime <- function(secs) {
   day2sec <- 60*60*24
   days <- secs/day2sec
}

When I try to run this from package/R I get...

Error in ss(file, echo = visibly, local = local, print.eval = output,  :
   /tmp/gpstime.R!CuSewT:2:0: unexpected end of input
1: secsToRDateTime <- function(secs) {
^

As I said, there are no problems when the script is run from my
home directory. This suggests that test scripts can no longer be
tested in a package's R directory?

Is this true?

Thanks,
Dominick


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

Re: [Rd] New behavior when running script in package directory?

[Dominick Samperi]

Thanks Ivan, looks like bug in ESS, but I only noticed this recently, so it
may have been triggered by changes in recent R versions.

On Wed, Jun 21, 2023 at 12:26 PM Ivan Krylov  wrote:

> On Wed, 21 Jun 2023 11:49:24 -0400
> Dominick Samperi  wrote:
>
> > 1. Why does Emacs/ESS behave differently depending on the
> > current working directory?
> > 2. Why is the signal package loaded automatically?
>
> There's a "package development mode" in ESS:
> https://github.com/emacs-ess/ESS/blob/master/lisp/ess-r-package.el
>
> I think that ESS automatically detects that you're inside a package
> directory and adjusts its behaviour. This could be related to
> "namespaced evaluation"
> 
> ("evaluate code in the context of the package being developed", sounds
> useful), but I'm not sure about that.
>
> > 3. Why is that temporary file /tmp/foo.R!djSwRn created?
>
> It's probably some part of ESS's mechanism of running R code. I don't
> see where the temporary file name is constructed (maybe a built-in
> Emacs function?), but it probably comes from
> .
> (Look for calls to .ess.source or .ess.ns_source.)
>
> > 4. What is that function ss() in the error message referring to?
>
> `ss` is a function defined by ESS in order to call R's source() in a
> way portable between a very wide range of R versions. (A comment in the
> same file says "Should work on *all* versions of R. Do not use _ in
> names, nor :: , nor 1L", which includes versions of R considered very
> old by now.):
>
> https://github.com/emacs-ess/ESS/blob/master/etc/ESSR/R/.basic.R#L178
>
> > 5. Could this be a virus? Under Ubuntu?
>
> A virus has little reason to be doing this to you. There's much more
> money to be made from malicious VSCode extensions than Emacs add-on
> packages.
>
> Since you've determined ESS to be causing the difference in the
> behaviour, perhaps
>  is the way
> to go? Unfortunately, I'm not a user of ESS or Emacs, so I'm going off
> what information I found on the Web, which may be outdated.
>
> --
> Best regards,
> Ivan
>

[[alternative HTML version deleted]]

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

Re: [Rd] New behavior when running script in package directory?

[Ivan Krylov]

On Wed, 21 Jun 2023 11:49:24 -0400
Dominick Samperi  wrote:

> 1. Why does Emacs/ESS behave differently depending on the
> current working directory?
> 2. Why is the signal package loaded automatically?

There's a "package development mode" in ESS:
https://github.com/emacs-ess/ESS/blob/master/lisp/ess-r-package.el

I think that ESS automatically detects that you're inside a package
directory and adjusts its behaviour. This could be related to
"namespaced evaluation"

("evaluate code in the context of the package being developed", sounds
useful), but I'm not sure about that.

> 3. Why is that temporary file /tmp/foo.R!djSwRn created?

It's probably some part of ESS's mechanism of running R code. I don't
see where the temporary file name is constructed (maybe a built-in
Emacs function?), but it probably comes from
.
(Look for calls to .ess.source or .ess.ns_source.)

> 4. What is that function ss() in the error message referring to?

`ss` is a function defined by ESS in order to call R's source() in a
way portable between a very wide range of R versions. (A comment in the
same file says "Should work on *all* versions of R. Do not use _ in
names, nor :: , nor 1L", which includes versions of R considered very
old by now.):

https://github.com/emacs-ess/ESS/blob/master/etc/ESSR/R/.basic.R#L178

> 5. Could this be a virus? Under Ubuntu?

A virus has little reason to be doing this to you. There's much more
money to be made from malicious VSCode extensions than Emacs add-on
packages.

Since you've determined ESS to be causing the difference in the
behaviour, perhaps
 is the way
to go? Unfortunately, I'm not a user of ESS or Emacs, so I'm going off
what information I found on the Web, which may be outdated.

-- 
Best regards,
Ivan

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

Re: [Rd] New behavior when running script in package directory?

[Dominick Samperi]

Thanks, there is no ~/.Rprofile, and I have no idea where ss() is defined.

On Wed, Jun 21, 2023 at 12:01 PM Bill Dunlap 
wrote:

> If ./Rprofile is not present and ~/.Rprofile is present then R will run
> the latter at startup.  Do you have a ~/.Rprofile that defines a ss()
> function?
>
> -Bill
>
> On Wed, Jun 21, 2023 at 8:50 AM Dominick Samperi 
> wrote:
>
>> Thanks, I checked for .Rprofile and .RData files. They are not present.
>> I also tried renaming my .emacs.d file in case the problem is due to
>> my Emacs configuration, but this didn't change anything.
>>
>> If I go to package/R, start R, and use source('foo.R'), there is no
>> problem.
>>
>> But if I use Emacs/ESS to run the script foo.R (with no .emacs.d) I get
>> an error referring to a temp file /tmp/foo.R!djSwRn, namely
>>
>> Error in ss(file, echo = visibly, local = local, print.eval = output,  :
>>   /tmp/foo.R!djSwRn:2:0: unexpected end of input
>> 1: foo <- function(secs) {
>>
>> Here are the contents of foo.R:
>> foo <- function(secs) {
>>   return(secs)
>> }
>>
>> What seems to be happening is this. After reading the script into Emacs
>> and
>> using Ctrl-n to start emacs, R starts, setwd() is run,
>> and then the signal package is attached (a dependency of packageA), and
>> I get the error message. There is no problem when Emacs is used to run
>> the script in my home directory.
>>
>> This raises a couple of questions:
>> 1. Why does Emacs/ESS behave differently depending on the
>> current working directory?
>> 2. Why is the signal package loaded automatically?
>> 3. Why is that temporary file /tmp/foo.R!djSwRn created?
>> 4. What is that function ss() in the error message referring to?
>> 5. Could this be a virus? Under Ubuntu?
>>
>> Thanks,
>> Dominick
>>
>>
>>
>>
>> On Wed, Jun 21, 2023 at 2:17 AM Jan van der Laan 
>> wrote:
>>
>> >
>> > Could there be a .Rprofile or .RData file in the directory where you
>> > start R? These are run/loaded when you start R when present (with the
>> > default arguments when starting R).
>> >
>> > HTH,
>> > Jan
>> >
>> >
>> >
>> > On 20-06-2023 23:38, Dominick Samperi wrote:
>> > > When I run a script foo.R containing some trivial code in my home
>> > > directory, via Emacs/ESS, everything works as expected: R
>> > > starts, and a setwd() command to set the working directory is
>> > > run automatically before the code in the script is run.
>> > >
>> > > But if I copy foo.R to some package/R directory strange
>> > > things happen. When I use Emacs/ESS to run the script
>> > > in its new location, R starts, and setwd() is called to set
>> > > the working directory, but then one or more libraries that the
>> > > package depends on are loaded, even though I am using no
>> > > libraries in foo.R.
>> > >
>> > > Now consider foo.R that contains the following trivial code:
>> > > secsToRDateTime <- function(secs) {
>> > >day2sec <- 60*60*24
>> > >days <- secs/day2sec
>> > > }
>> > >
>> > > When I try to run this from package/R I get...
>> > >
>> > > Error in ss(file, echo = visibly, local = local, print.eval =
>> output,  :
>> > >/tmp/gpstime.R!CuSewT:2:0: unexpected end of input
>> > > 1: secsToRDateTime <- function(secs) {
>> > > ^
>> > >
>> > > As I said, there are no problems when the script is run from my
>> > > home directory. This suggests that test scripts can no longer be
>> > > tested in a package's R directory?
>> > >
>> > > Is this true?
>> > >
>> > > Thanks,
>> > > Dominick
>> > >
>> > >   [[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
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

[[alternative HTML version deleted]]

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

Re: [Rd] New behavior when running script in package directory?

[Bill Dunlap]

If ./Rprofile is not present and ~/.Rprofile is present then R will run the
latter at startup.  Do you have a ~/.Rprofile that defines a ss() function?

-Bill

On Wed, Jun 21, 2023 at 8:50 AM Dominick Samperi 
wrote:

> Thanks, I checked for .Rprofile and .RData files. They are not present.
> I also tried renaming my .emacs.d file in case the problem is due to
> my Emacs configuration, but this didn't change anything.
>
> If I go to package/R, start R, and use source('foo.R'), there is no
> problem.
>
> But if I use Emacs/ESS to run the script foo.R (with no .emacs.d) I get
> an error referring to a temp file /tmp/foo.R!djSwRn, namely
>
> Error in ss(file, echo = visibly, local = local, print.eval = output,  :
>   /tmp/foo.R!djSwRn:2:0: unexpected end of input
> 1: foo <- function(secs) {
>
> Here are the contents of foo.R:
> foo <- function(secs) {
>   return(secs)
> }
>
> What seems to be happening is this. After reading the script into Emacs and
> using Ctrl-n to start emacs, R starts, setwd() is run,
> and then the signal package is attached (a dependency of packageA), and
> I get the error message. There is no problem when Emacs is used to run
> the script in my home directory.
>
> This raises a couple of questions:
> 1. Why does Emacs/ESS behave differently depending on the
> current working directory?
> 2. Why is the signal package loaded automatically?
> 3. Why is that temporary file /tmp/foo.R!djSwRn created?
> 4. What is that function ss() in the error message referring to?
> 5. Could this be a virus? Under Ubuntu?
>
> Thanks,
> Dominick
>
>
>
>
> On Wed, Jun 21, 2023 at 2:17 AM Jan van der Laan 
> wrote:
>
> >
> > Could there be a .Rprofile or .RData file in the directory where you
> > start R? These are run/loaded when you start R when present (with the
> > default arguments when starting R).
> >
> > HTH,
> > Jan
> >
> >
> >
> > On 20-06-2023 23:38, Dominick Samperi wrote:
> > > When I run a script foo.R containing some trivial code in my home
> > > directory, via Emacs/ESS, everything works as expected: R
> > > starts, and a setwd() command to set the working directory is
> > > run automatically before the code in the script is run.
> > >
> > > But if I copy foo.R to some package/R directory strange
> > > things happen. When I use Emacs/ESS to run the script
> > > in its new location, R starts, and setwd() is called to set
> > > the working directory, but then one or more libraries that the
> > > package depends on are loaded, even though I am using no
> > > libraries in foo.R.
> > >
> > > Now consider foo.R that contains the following trivial code:
> > > secsToRDateTime <- function(secs) {
> > >day2sec <- 60*60*24
> > >days <- secs/day2sec
> > > }
> > >
> > > When I try to run this from package/R I get...
> > >
> > > Error in ss(file, echo = visibly, local = local, print.eval = output,
> :
> > >/tmp/gpstime.R!CuSewT:2:0: unexpected end of input
> > > 1: secsToRDateTime <- function(secs) {
> > > ^
> > >
> > > As I said, there are no problems when the script is run from my
> > > home directory. This suggests that test scripts can no longer be
> > > tested in a package's R directory?
> > >
> > > Is this true?
> > >
> > > Thanks,
> > > Dominick
> > >
> > >   [[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
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] New behavior when running script in package directory?

[Dominick Samperi]

Thanks, I checked for .Rprofile and .RData files. They are not present.
I also tried renaming my .emacs.d file in case the problem is due to
my Emacs configuration, but this didn't change anything.

If I go to package/R, start R, and use source('foo.R'), there is no problem.

But if I use Emacs/ESS to run the script foo.R (with no .emacs.d) I get
an error referring to a temp file /tmp/foo.R!djSwRn, namely

Error in ss(file, echo = visibly, local = local, print.eval = output,  :
  /tmp/foo.R!djSwRn:2:0: unexpected end of input
1: foo <- function(secs) {

Here are the contents of foo.R:
foo <- function(secs) {
  return(secs)
}

What seems to be happening is this. After reading the script into Emacs and
using Ctrl-n to start emacs, R starts, setwd() is run,
and then the signal package is attached (a dependency of packageA), and
I get the error message. There is no problem when Emacs is used to run
the script in my home directory.

This raises a couple of questions:
1. Why does Emacs/ESS behave differently depending on the
current working directory?
2. Why is the signal package loaded automatically?
3. Why is that temporary file /tmp/foo.R!djSwRn created?
4. What is that function ss() in the error message referring to?
5. Could this be a virus? Under Ubuntu?

Thanks,
Dominick




On Wed, Jun 21, 2023 at 2:17 AM Jan van der Laan  wrote:

>
> Could there be a .Rprofile or .RData file in the directory where you
> start R? These are run/loaded when you start R when present (with the
> default arguments when starting R).
>
> HTH,
> Jan
>
>
>
> On 20-06-2023 23:38, Dominick Samperi wrote:
> > When I run a script foo.R containing some trivial code in my home
> > directory, via Emacs/ESS, everything works as expected: R
> > starts, and a setwd() command to set the working directory is
> > run automatically before the code in the script is run.
> >
> > But if I copy foo.R to some package/R directory strange
> > things happen. When I use Emacs/ESS to run the script
> > in its new location, R starts, and setwd() is called to set
> > the working directory, but then one or more libraries that the
> > package depends on are loaded, even though I am using no
> > libraries in foo.R.
> >
> > Now consider foo.R that contains the following trivial code:
> > secsToRDateTime <- function(secs) {
> >day2sec <- 60*60*24
> >days <- secs/day2sec
> > }
> >
> > When I try to run this from package/R I get...
> >
> > Error in ss(file, echo = visibly, local = local, print.eval = output,  :
> >/tmp/gpstime.R!CuSewT:2:0: unexpected end of input
> > 1: secsToRDateTime <- function(secs) {
> > ^
> >
> > As I said, there are no problems when the script is run from my
> > home directory. This suggests that test scripts can no longer be
> > tested in a package's R directory?
> >
> > Is this true?
> >
> > Thanks,
> > Dominick
> >
> >   [[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
>

[[alternative HTML version deleted]]

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

Re: [Rd] Installation of R-4.3.1 with intel 2022

[Giuseppe Calò]

Ok, I’ll reinstall in /juno/opt/sources/R/R-4.3.1-intel21/

Other outputs:


[root@juno-n001][/root]>  tail -n 20 
/juno/opt/sources/R/R-4.3.1-intel21/tests/d-p-q-r-tst-2.Rout.fail 

 0  1  2  3  4  5  6 
13 22 30 22 10  1  2 
> (t2 <- table(rbinom(100, 10*M, pr = 1e-10)) )

 0  1  2  3  4  5 
10 35 28 18  4  5 
> stopifnot(0:6 %in% names(tt), sum(tt) == 100, sum(t2) == 100) ## no NaN there
> ## related qbinom() tests:
> k <- 0:32
> for(n in c((M+1)/2, M, 2*M, 10*M)) {
+ for(pr in c(1e-8, 1e-9, 1e-10)) {
+ nDup <- !duplicated( pb <- pbinom(k, n, pr) )
+ qb <- qbinom(pb[nDup], n, pr)
+ pn1 <- pb[nDup] < if(b64) 1 else 1 - 3*.Machine$double.eps
+ stopifnot(k[nDup][pn1] == qb[pn1]) ##^ fudge needed (Linux 32-b)
+ }
+ }
Error: k[nDup][pn1] == qb[pn1] are not all TRUE
Execution halted



/juno/opt/intel-2021.6.0/R/4.3.1/bin/R

R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
Copyright (C) 2023 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

>  str(.Machine)
List of 29
 $ double.eps   : num 2.22e-16
 $ double.neg.eps   : num 1.11e-16
 $ double.xmin  : num 2.23e-308
 $ double.xmax  : num 1.8e+308
 $ double.base  : int 2
 $ double.digits: int 53
 $ double.rounding  : int 5
 $ double.guard : int 0
 $ double.ulp.digits: int -52
 $ double.neg.ulp.digits: int -53
 $ double.exponent  : int 11
 $ double.min.exp   : int -1022
 $ double.max.exp   : int 1024
 $ integer.max  : int 2147483647
 $ sizeof.long  : int 8
 $ sizeof.longlong  : int 8
 $ sizeof.longdouble: int 16
 $ sizeof.pointer   : int 8
 $ sizeof.time_t: int 8
 $ longdouble.eps   : num 1.08e-19
 $ longdouble.neg.eps   : num 5.42e-20
 $ longdouble.digits: int 64
 $ longdouble.rounding  : int 5
 $ longdouble.guard : int 0
 $ longdouble.ulp.digits: int -63
 $ longdouble.neg.ulp.digits: int -64
 $ longdouble.exponent  : int 15
 $ longdouble.min.exp   : int -16382
 $ longdouble.max.exp   : int 16384

Thanks

> On 21 Jun 2023, at 12:44, Martin Maechler  wrote:
> 
>> Giuseppe Calò 
>>on Wed, 21 Jun 2023 09:17:14 +0200 writes:
> 
>> Thanks Tomas,
>> With my configure (I follower Admin manual for intel) and deleting  
>> HAVE_MATHERR in config I’m able to perform, configure, make and make 
>> install, only make check has this issue:
> 
>> running code in 'array-subset.R' ... OK
>> running code in 'reg-tests-1a.R' ... OK
>> running code in 'reg-tests-1b.R' ... OK
>> running code in 'reg-tests-1c.R' ... OK
>> running code in 'reg-tests-1d.R' ... OK
>> running code in 'reg-tests-1e.R' ... OK
>> running code in 'reg-tests-2.R' ... OK
>> comparing 'reg-tests-2.Rout' to './reg-tests-2.Rout.save' ... OK
>> running code in 'reg-examples1.R' ... OK
>> running code in 'reg-examples2.R' ... OK
>> running code in 'reg-packages.R' ... OK
>> running code in 'p-qbeta-strict-tst.R' ... OK
>> running code in 'd-p-q-r-tst-2.R' ...make[3]: *** [Makefile.common:117: 
>> d-p-q-r-tst-2.Rout] Error 1
>> make[3]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
>> make[2]: *** [Makefile.common:320: test-Reg] Error 2
>> make[2]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
>> make[1]: *** [Makefile.common:190: test-all-basics] Error 1
>> make[1]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
>> make: *** [Makefile:307: check] Error 2
> 
>> Do you have some suggestion about this error?
> 
> Only if you tell us more about the resulting
> 
>  d-p-q-r-tst-2.Rout.fail
>^   file
> 
> e.g. giving us the last 20 lines or so, e.g. from
>  tail -n 20 /juno/opt/sources/R/R-4.3.1-intel21/tests/d-p-q-r-tst-2.Rout.fail 
> 
> Also, in addition to the output of sessionInfo(),  the  output of
> 
>   str(.Machine)
> 
> maybe interesting.  Once I'd see these, I might have to ask further questions
> (possibly off-mailinglist), so it'd be good if you keep the
> R "installation" in  '/juno/opt/sources/R/R-4.3.1-intel21/  for
> minor "experiments".
> 
> Best regards,
> Martin
> 
> Martin Maechler
> ETH Zurich  and  R Core team
> 
>   
>> Checking MKL on installing R it is:
> 
>> Matrix products: default
>> BLAS/LAPACK: 
>> /juno/opt/intel/oneapi_2022.2.0/mkl/2022

Re: [Rd] Installation of R-4.3.1 with intel 2022

[Martin Maechler]

> Giuseppe Calò 
> on Wed, 21 Jun 2023 09:17:14 +0200 writes:

> Thanks Tomas,
> With my configure (I follower Admin manual for intel) and deleting  
HAVE_MATHERR in config I’m able to perform, configure, make and make install, 
only make check has this issue:

> running code in 'array-subset.R' ... OK
> running code in 'reg-tests-1a.R' ... OK
> running code in 'reg-tests-1b.R' ... OK
> running code in 'reg-tests-1c.R' ... OK
> running code in 'reg-tests-1d.R' ... OK
> running code in 'reg-tests-1e.R' ... OK
> running code in 'reg-tests-2.R' ... OK
> comparing 'reg-tests-2.Rout' to './reg-tests-2.Rout.save' ... OK
> running code in 'reg-examples1.R' ... OK
> running code in 'reg-examples2.R' ... OK
> running code in 'reg-packages.R' ... OK
> running code in 'p-qbeta-strict-tst.R' ... OK
> running code in 'd-p-q-r-tst-2.R' ...make[3]: *** [Makefile.common:117: 
d-p-q-r-tst-2.Rout] Error 1
> make[3]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
> make[2]: *** [Makefile.common:320: test-Reg] Error 2
> make[2]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
> make[1]: *** [Makefile.common:190: test-all-basics] Error 1
> make[1]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
> make: *** [Makefile:307: check] Error 2

> Do you have some suggestion about this error?

Only if you tell us more about the resulting

  d-p-q-r-tst-2.Rout.fail
^   file

e.g. giving us the last 20 lines or so, e.g. from
  tail -n 20 /juno/opt/sources/R/R-4.3.1-intel21/tests/d-p-q-r-tst-2.Rout.fail 

Also, in addition to the output of sessionInfo(),  the  output of

   str(.Machine)

maybe interesting.  Once I'd see these, I might have to ask further questions
(possibly off-mailinglist), so it'd be good if you keep the
R "installation" in  '/juno/opt/sources/R/R-4.3.1-intel21/  for
minor "experiments".

Best regards,
Martin

Martin Maechler
ETH Zurich  and  R Core team


> Checking MKL on installing R it is:

> Matrix products: default
> BLAS/LAPACK: 
/juno/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_lp64.so.2;
  LAPACK version 3.9.0

> And 

> ldd /juno/opt/intel-2021.6.0/R/4.3.1/lib64/R/lib/libRblas.so| grep mkl
> libmkl_intel_lp64.so.2 => 
/juno/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_lp64.so.2 
(0x7f01ba508000)
> libmkl_intel_thread.so.2 => 
/juno/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_thread.so.2
 (0x7f01b6d94000)
> libmkl_core.so.2 => 
/juno/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_core.so.2 
(0x7f01b29be000)

> About you, is R using right mkl? (Oneapi mkl)

> Thanks,
> Giuseppe.

> ———
> Giuseppe Calò

> Fondazione CMCC
> Centro Euro-Mediterraneo sui Cambiamenti Climatici presso Complesso 
Ecotekne 
> Università del Salento - Strada Prov.le Lecce - Monteroni 73100 Lecce  IT
> http://www.cmcc.it
> https://goo.gl/maps/wtahPDbNVen

> mobile: (+39) 3208190020
> email: giuseppe.c...@cmcc.it

> Le informazioni contenute in questo messaggio di posta elettronica e 
negli allegati se presenti sono riservate e confidenziali: ne è vietata la 
diffusione in qualsiasi modo o forma (GDPR 2016/679).
> Qualora lei non fosse il destinatario del messaggio, la invito a non 
diffonderlo e ad eliminarlo dandone gentilmente comunicazione al mittente.

> The information included in this e-mail and any attachments are 
confidential and may also be privileged (GDPR 2016/679).
> If you are not the correct recipient, you are kindly requested to notify 
the sender immediately, to cancel it and not disclose the contents to any other 
person.




>> On 21 Jun 2023, at 09:10, Tomas Kalibera  
wrote:
>> 
>> 
>> On 6/20/23 18:47, Giuseppe Calò wrote:
>>> Hi all,
>>> I have the issue:
>>> 
>>> icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I. 
-I../../src/include -I../../src/include  -I/usr/local/include -I../../src/nmath 
-DHAVE_CONFIG_H   -fopenmp -fpic  -g -O3 -wd188 -ip -mp  -c eval.c -o eval.o
>>> arithmetic.c(66): warning #274: declaration is not visible outside of 
function
>>> int matherr(struct exception *exc)
>>> ^
>>> 
>>> arithmetic.c(68): error: pointer to incomplete class type is not allowed
>>> switch (exc->type) {
>>> ^
>>> 
>>> arithmetic.c(69): error: identifier "DOMAIN" is undefined
>>> case DOMAIN:
>>> ^
>>> 
>>> arithmetic.c(70): error: identifier "SING" is undefined
>>> case SING:
>>> ^
>>> 
>>> arithmetic.c(73): error: identifier "OVERFLOW" is undefined
>>> case OVERFLOW:
>>> ^
>>> 
>>> arithmetic.c(76): error: identifier "UNDERFLOW" is undefined
>>> case UNDERFLOW:
>>> ^
>>> 
   

Re: [Rd] Installation of R-4.3.1 with intel 2022

[Giuseppe Calò]

Thanks Tomas,
With my configure (I follower Admin manual for intel) and deleting  
HAVE_MATHERR in config I’m able to perform, configure, make and make install, 
only make check has this issue:

running code in 'array-subset.R' ... OK
running code in 'reg-tests-1a.R' ... OK
running code in 'reg-tests-1b.R' ... OK
running code in 'reg-tests-1c.R' ... OK
running code in 'reg-tests-1d.R' ... OK
running code in 'reg-tests-1e.R' ... OK
running code in 'reg-tests-2.R' ... OK
  comparing 'reg-tests-2.Rout' to './reg-tests-2.Rout.save' ... OK
running code in 'reg-examples1.R' ... OK
running code in 'reg-examples2.R' ... OK
running code in 'reg-packages.R' ... OK
running code in 'p-qbeta-strict-tst.R' ... OK
running code in 'd-p-q-r-tst-2.R' ...make[3]: *** [Makefile.common:117: 
d-p-q-r-tst-2.Rout] Error 1
make[3]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
make[2]: *** [Makefile.common:320: test-Reg] Error 2
make[2]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
make[1]: *** [Makefile.common:190: test-all-basics] Error 1
make[1]: Leaving directory '/juno/opt/sources/R/R-4.3.1-intel21/tests'
make: *** [Makefile:307: check] Error 2

Do you have some suggestion about this error?


Checking MKL on installing R it is:

Matrix products: default
BLAS/LAPACK: 
/juno/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_lp64.so.2;
  LAPACK version 3.9.0

And 

ldd /juno/opt/intel-2021.6.0/R/4.3.1/lib64/R/lib/libRblas.so| grep mkl
libmkl_intel_lp64.so.2 => 
/juno/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_lp64.so.2 
(0x7f01ba508000)
libmkl_intel_thread.so.2 => 
/juno/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_thread.so.2
 (0x7f01b6d94000)
libmkl_core.so.2 => 
/juno/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_core.so.2 
(0x7f01b29be000)

About you, is R using right mkl? (Oneapi mkl)

Thanks,
Giuseppe.

———
Giuseppe Calò

Fondazione CMCC
Centro Euro-Mediterraneo sui Cambiamenti Climatici presso Complesso Ecotekne 
Università del Salento - Strada Prov.le Lecce - Monteroni 73100 Lecce  IT
http://www.cmcc.it
https://goo.gl/maps/wtahPDbNVen

mobile: (+39) 3208190020
email: giuseppe.c...@cmcc.it

Le informazioni contenute in questo messaggio di posta elettronica e negli 
allegati se presenti sono riservate e confidenziali: ne è vietata la diffusione 
in qualsiasi modo o forma (GDPR 2016/679).
Qualora lei non fosse il destinatario del messaggio, la invito a non 
diffonderlo e ad eliminarlo dandone gentilmente comunicazione al mittente.

The information included in this e-mail and any attachments are confidential 
and may also be privileged (GDPR 2016/679).
If you are not the correct recipient, you are kindly requested to notify the 
sender immediately, to cancel it and not disclose the contents to any other 
person.




> On 21 Jun 2023, at 09:10, Tomas Kalibera  wrote:
> 
> 
> On 6/20/23 18:47, Giuseppe Calò wrote:
>> Hi all,
>> I have the issue:
>> 
>> icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I. 
>> -I../../src/include -I../../src/include  -I/usr/local/include 
>> -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -g -O3 -wd188 -ip -mp  
>> -c eval.c -o eval.o
>> arithmetic.c(66): warning #274: declaration is not visible outside of 
>> function
>>   int matherr(struct exception *exc)
>>  ^
>> 
>> arithmetic.c(68): error: pointer to incomplete class type is not allowed
>>   switch (exc->type) {
>>   ^
>> 
>> arithmetic.c(69): error: identifier "DOMAIN" is undefined
>>   case DOMAIN:
>>^
>> 
>> arithmetic.c(70): error: identifier "SING" is undefined
>>   case SING:
>>^
>> 
>> arithmetic.c(73): error: identifier "OVERFLOW" is undefined
>>   case OVERFLOW:
>>^
>> 
>> arithmetic.c(76): error: identifier "UNDERFLOW" is undefined
>>   case UNDERFLOW:
>>^
>> 
>> arithmetic.c(77): error: pointer to incomplete class type is not allowed
>>  exc->retval = 0.0;
>> 
>> icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I. 
>> -I../../src/include -I../../src/include  -I/usr/local/include 
>> -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -g -O3 -wd188 -ip -mp  
>> -c flexiblas.c -o flexiblas.o
>> icc: command line remark #10148: option '-mp' not supported
>> compilation aborted for arithmetic.c (code 2)
>> make[3]: *** [../../Makeconf:129: arithmetic.o] Error 2
>> make[3]: *** Waiting for unfinished jobs
>> icc: command line remark #10148: option '-mp' not supported
>> make[3]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src/main'
>> make[2]: *** [Makefile:140: R] Error 2
>> make[2]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src/main'
>> make[1]: *** [Makefile:28: R] Error 1
>> make[1]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src'
>> make: *** [Makefile:62: R] Error 1
>> 
>> with oneapi-2022.1.0/compi

Re: [Rd] codetools wrongly complains about lazy evaluation in S4 methods

[Martin Maechler]

> Martin Maechler 
> on Fri, 16 Jun 2023 11:41:12 +0200 writes:

> Mikael Jagan 
> on Thu, 15 Jun 2023 22:00:45 -0400 writes:

>> On 2023-06-15 5:25 pm, Hervé Pagès wrote:
>>> Oh but I see now that you've already tried this in your
>>> R/AllGenerics.R, sorry for missing that,

> yes, this one:

>   setGeneric("qr.X",
>function(qr, complete = FALSE, ncol, ...)
>standardGeneric("qr.X"),
>useAsDefault = function(qr, complete = FALSE, ncol, ...) {
>if(missing(ncol))
>base::qr.X(qr, complete = complete)
>else base::qr.X(qr, complete = complete, ncol = ncol)
>},
>signature = "qr")
> 
> where the 'signature = "qr"' is perfect (and as Hervé suggests).
> 
> but the complication in useAsDefault = ..  is really a bit ugly
> ... notably if one compares with the nice original  base :: qr.X ()

In spite of the "ugliness" (above) and of the "conflict
rules"-resolution I've talked about below,
I've now committed the above + implicit generic definition to
R-devel's {methods} package.

After all, it provides a clean situation also for other S4-using
developers.

I'm still musing if this is a bug fix to be back ported to the
R-4-3-branch eventually.

Best,
Martin

> >> but that you worry about the following message being 
> >> disruptive on CRAN:
> >> 
> >>     The following object is masked from 'package:base':
> >> 
> >>     qr.X
> >> 
> >> Why would that be? As long as you only define methods for
> >> objects that **you** control everything is fine. In other
> >> words you're not allowed to define a method for "qr"
> >> objects because that method would override
> >> base::qr.X(). But the generic itself and the method that
> >> you define for your objects don't override anything so
> >> should not disrupt anything.
> 
> > Yes, maybe it would be fine in principle, and of course
> > many popular packages emit startup messages.  Still, in
> > practice, I think that people are quite accustomed to
> > library(Matrix) being "silent", and probably a nontrivial
> > fraction of our reverse dependencies would encounter new
> > NOTEs about differences between *.Rout and *.Rout.save,
> > etc.
> 
> I tend to agree with Hervé that the  "masked" warning here is
> a false positive.
> 
> I also agree with Mikael  that we would not want this for every
> default use of   library(Matrix)
> 
> I believe we should fix it by using conflictRules(), and from
> reading ?conflictRules I understand we could do that by setting
> 
>   options(conflict.policy = list(mask.ok = "qr.X"))
> 
> possibly even in Matrix package's load or attach hook
> [[and if really really necessary even as hack inside library()'s checks]]
> 
> > The fraction of users who will ever call this method for
> > qr.X is very very small compared to the fraction who will
> > be confused or annoyed by the message.  Hence my hope that
> > an implicit generic qr.X could become part of package
> > methods, notably as an implicit generic qr.R already lives
> > there ...
> 
> > Or maybe there is a way for Matrix to define qr.X as an
> > implicit generic without creating other problems, but my
> > experiments with setGenericImplicit were not promising ...
> 
> In principle, I'd say that setGenericImplicit() would be a good
> / "the correct" approach,  but as you already tried
> unsuccessfully, I'm not claiming the principle.
> 
> Martin
> 
> 
> > Mikael
> 
> >> H.

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

Re: [Rd] Installation of R-4.3.1 with intel 2022

[Tomas Kalibera]

On 6/20/23 18:47, Giuseppe Calò wrote:

Hi all,
I have the issue:

icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I. 
-I../../src/include -I../../src/include  -I/usr/local/include -I../../src/nmath 
-DHAVE_CONFIG_H   -fopenmp -fpic  -g -O3 -wd188 -ip -mp  -c eval.c -o eval.o
arithmetic.c(66): warning #274: declaration is not visible outside of function
   int matherr(struct exception *exc)
  ^

arithmetic.c(68): error: pointer to incomplete class type is not allowed
   switch (exc->type) {
   ^

arithmetic.c(69): error: identifier "DOMAIN" is undefined
   case DOMAIN:
^

arithmetic.c(70): error: identifier "SING" is undefined
   case SING:
^

arithmetic.c(73): error: identifier "OVERFLOW" is undefined
   case OVERFLOW:
^

arithmetic.c(76): error: identifier "UNDERFLOW" is undefined
   case UNDERFLOW:
^

arithmetic.c(77): error: pointer to incomplete class type is not allowed
exc->retval = 0.0;

icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I. 
-I../../src/include -I../../src/include  -I/usr/local/include -I../../src/nmath 
-DHAVE_CONFIG_H   -fopenmp -fpic  -g -O3 -wd188 -ip -mp  -c flexiblas.c -o 
flexiblas.o
icc: command line remark #10148: option '-mp' not supported
compilation aborted for arithmetic.c (code 2)
make[3]: *** [../../Makeconf:129: arithmetic.o] Error 2
make[3]: *** Waiting for unfinished jobs
icc: command line remark #10148: option '-mp' not supported
make[3]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src/main'
make[2]: *** [Makefile:140: R] Error 2
make[2]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src/main'
make[1]: *** [Makefile:28: R] Error 1
make[1]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src'
make: *** [Makefile:62: R] Error 1

with oneapi-2022.1.0/compiler-rt/2022.1.0; oneapi-2022.1.0/mkl/2022.1.0 while 
building R-4.3.1 on redhat 8.4 glibc2.28-189

I followed a workaround proposed:
https://community.intel.com/t5/Intel-C-Compiler/Error-when-compiling-R-from-source-code-ubuntu-18-04/m-p/1176401/thread-id/36575
 


Deactivate  HAVE_MATHERR macro in src/include/config.h


Hi Giuseppe,

thanks for the report. Undefining HAVE_MATHERR seems a valid work-around 
to me, based on reading the thread above and the sources.


We could improve this in R, if keeping this code, at least improve the 
configure check so that it also tests for the presence of the macros.



Using this workaroud I get R with:

BLAS/LAPACK: 
/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_lp64.so.2;  
LAPACK version 3.9.0

is correct?

Is these a way to avoid arithmetic issue?

My configure is:

module load intel-2021.6.0/2021.6.0 oneapi-2022.1.0/mkl
MKL="-L${MKLROOT}/lib/intel64 -lmkl_gf_lp64 -lmkl_core -lmkl_gnu_thread -dl 
-fopenmp"
export CC="icc -std=c99"
export CFLAGS="-g -O3 -wd188 -ip -mp"
export FC=ifort
export FLAGS="-g -O3 -mp"
export CXX=icpc
export CXXFLAGS="-g -O3 -mp"
SHLIB_CXXLD=icpc
export MKL_INTERFACE_LAYER=GNU,LP64
export MKL_THREADING_LAYER=GNU
./configure --prefix=/opt/intel-2021.6.0/R/4.3.1 --with-blas="$MKL" 
--with-lapack  --enable-memory-profiling --enable-BLAS-shlib --enable-R-shlib 
--enable-R-static-lib --with-pcre2


AFAIK, neither icc nor MKL is regularly tested with R/CRAN packages, so 
the risk of running into some issues is somewhat higher than for say GCC 
and the reference BLAS/LAPACK.


Some hints on using icc and MKL can be found in the R Admin manual, 
https://cran.r-project.org/doc/manuals/r-release/R-admin.html. Unless 
you have done that already, you might want to check your configuration 
against those, I didn't spot any obvious issue. If you find any other 
problem, please report, so that it could be fixed or the hints updated.


Thanks,
Tomas



Thanks a lot,
Giuseppe.

———
Giuseppe Calò

Fondazione CMCC
Centro Euro-Mediterraneo sui Cambiamenti Climatici presso Complesso Ecotekne
Università del Salento - Strada Prov.le Lecce - Monteroni 73100 Lecce  IT
http://www.cmcc.it 
https://goo.gl/maps/wtahPDbNVen

mobile: (+39) 3208190020
email: giuseppe.c...@cmcc.it

Le informazioni contenute in questo messaggio di posta elettronica e negli 
allegati se presenti sono riservate e confidenziali: ne è vietata la diffusione 
in qualsiasi modo o forma (GDPR 2016/679).
Qualora lei non fosse il destinatario del messaggio, la invito a non 
diffonderlo e ad eliminarlo dandone gentilmente comunicazione al mittente.

The information included in this e-mail and any attachments are confidential 
and may also be privileged (GDPR 2016/679).
If you are not the correct recipient, you are kindly requested to notify the 
sender immediately, to cancel it and not disclose the contents to any other 
person.





[[alternat