Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-14 Thread Uwe Ligges 



On 13.01.2024 15:01, Uwe Ligges wrote:
Fascinating, now it worked with the latest winbuilder submission 3 times 
in a row when I checked it manually. So maybe Ivan was right and there 
was a very demanding set of other packages compiling at the same time?

I don't know.

Serge, Can you somply submit your latest winbuilder upload to CRAN?


Really, I inspected some more. The underlying issue is simple:
The C++ compiler used under Windows asks for precomitted memory. If 
several processes are running at the same time, a lot of memory is 
precomitted. And Windows does not use it for other processes, even if 
almost nothing is actually used.
So while the used memory may be around 50GB, all of the rest (of 756 GB 
including swap space) may have been precomitted (but unused) and new 
processes failed to start correctly. G.


Best,
Uwe Ligges






Best,
Uwe Ligges



On 13.01.2024 14:12, Uwe Ligges wrote:

I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.

My suspicion is currently a strange mix of cmd.exe and sh.exe calls. 
But this is a very wild guess.


Best,
Uwe

On 13.01.2024 14:08, Uwe Ligges wrote:



On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:

В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:


After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out


I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated

3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times

I got a lot of interesting errors, including the "Bad address":

Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found

0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299

0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455

-bash: fork: retry: Resource temporarily unavailable

-bash: R-devel/bin/Rscript.exe: Bad address


The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which 
may be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or 
more (depending in the machine) and additionally 500GB swap space on 
SSD.


Best,
Uwe



Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)

I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.



__
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] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-13 Thread Serge 

Thank you both very much for your feedback.
I'll submit the package tomorrow and see...

Best,
Serge



Le 13/01/2024 à 15:01, Uwe Ligges a écrit :
Fascinating, now it worked with the latest winbuilder submission 3 times in a row when I checked it 
manually. So maybe Ivan was right and there was a very demanding set of other packages compiling at 
the same time?

I don't know.

Serge, Can you somply submit your latest winbuilder upload to CRAN?

Best,
Uwe Ligges



On 13.01.2024 14:12, Uwe Ligges wrote:

I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.

My suspicion is currently a strange mix of cmd.exe and sh.exe calls. But this 
is a very wild guess.

Best,
Uwe

On 13.01.2024 14:08, Uwe Ligges wrote:



On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:

В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:


After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out


I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated

3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times

I got a lot of interesting errors, including the "Bad address":

Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found

0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299

0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455

-bash: fork: retry: Resource temporarily unavailable

-bash: R-devel/bin/Rscript.exe: Bad address


The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which may be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or more (depending in the 
machine) and additionally 500GB swap space on SSD.


Best,
Uwe



Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)

I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.



__
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] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-13 Thread Uwe Ligges 
Fascinating, now it worked with the latest winbuilder submission 3 times 
in a row when I checked it manually. So maybe Ivan was right and there 
was a very demanding set of other packages compiling at the same time?

I don't know.

Serge, Can you somply submit your latest winbuilder upload to CRAN?

Best,
Uwe Ligges



On 13.01.2024 14:12, Uwe Ligges wrote:

I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.

My suspicion is currently a strange mix of cmd.exe and sh.exe calls. But 
this is a very wild guess.


Best,
Uwe

On 13.01.2024 14:08, Uwe Ligges wrote:



On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:

В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:


After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out


I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated

3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times

I got a lot of interesting errors, including the "Bad address":

Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found

0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299

0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455

-bash: fork: retry: Resource temporarily unavailable

-bash: R-devel/bin/Rscript.exe: Bad address


The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which may 
be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or 
more (depending in the machine) and additionally 500GB swap space on SSD.


Best,
Uwe



Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)

I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.



__
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] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-13 Thread Uwe Ligges 

I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.

My suspicion is currently a strange mix of cmd.exe and sh.exe calls. But 
this is a very wild guess.


Best,
Uwe

On 13.01.2024 14:08, Uwe Ligges wrote:



On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:

В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:


After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out


I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated

3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times

I got a lot of interesting errors, including the "Bad address":

Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found

0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299

0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455

-bash: fork: retry: Resource temporarily unavailable

-bash: R-devel/bin/Rscript.exe: Bad address


The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which may 
be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or 
more (depending in the machine) and additionally 500GB swap space on SSD.


Best,
Uwe



Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)

I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.



__
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] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-13 Thread Uwe Ligges 



On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:

В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:


After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out


I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated

3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times

I got a lot of interesting errors, including the "Bad address":

Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found

0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299

0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455

-bash: fork: retry: Resource temporarily unavailable

-bash: R-devel/bin/Rscript.exe: Bad address


The above indeed happens if not sufficient memory would be available.
Important to know: This includes unused but committed memory which may 
be a lot.
But I doubt it is the case on winbuilder as the machines has 256GB or 
more (depending in the machine) and additionally 500GB swap space on SSD.


Best,
Uwe



Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)

I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.

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

Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-13 Thread Ivan Krylov via R-package-devel 
В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:

> After somme minor midficiations, I make a try on the winbuilder site.
> I was able to build the archive with the static library
> but I get again a Bad address error. You can have a look to
> 
> https://win-builder.r-project.org/bw47qsMX3HTd/00install.out

I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); getchar();
so that almost all physical memory is allocated

3. Run gcc -DFOO=`/path/to/Rscript -e 'some script'` & many times

I got a lot of interesting errors, including the "Bad address":

Warnings:
1: .getGeneric(f, , package) : internal error -4 in R_decompress1
2: package "methods" in options("defaultPackages") was not found

0 [main] bash (2892) child_copy: cygheap read copy failed,
0x0..0x800025420, done 0, windows pid 2892, Win32 error 299

0 [main] bash (3256) C:\rtools43\usr\bin\bash.exe: *** fatal error in
forked process - MEM_COMMIT failed, Win32 error 1455

-bash: fork: retry: Resource temporarily unavailable

-bash: R-devel/bin/Rscript.exe: Bad address

Your package is written in C++, but that by itself shouldn't disqualify
it. On my Linux computer, /usr/bin/time R -e
'install.packages("MixAll")' says that the installation takes slightly
less than a gigabyte of memory ("912516maxresident k"), which is par
the course for such packages. (My small Rcpp-using package takes
approximately half a gigabyte by the same metric.)

I'm still not 100% sure (if Win-Builder is running out of memory, why
are you seeing "Bad address" only and not the rest of the carnage?),
but I'm not seeing a problem with your package, either. If EFAULT is
Cygwin's way of saying "I caught a bad pointer in your system call"
(which, I must stress, is happening inside /bin/sh, not your package
or even R at all), it's not impossible that Win-Builder is having
hardware problems. Unfortunately, they take a lot of effort and
downtime to diagnose and could be hiding anywhere from RAM to the power
supply.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-12 Thread Serge 

Hi Ivan,

After somme minor midficiations, I make a try on the winbuilder site.
I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out

Thanks for your help,
Serge

Le 12/01/2024 à 20:14, Ivan Krylov a écrit :

В Fri, 12 Jan 2024 19:09:29 +0100
Serge  пишет:


I updated the package rtkore one month ago, fixing a compilation
problem on windows devel platform.

MixAll has a dependency to rtkore. Thus, I suspect that the error
reported below is due to the presence of the old version of rtkore on
the pretest infrastructure of the CRAN.


:

/usr/bin/make -C projects/Clustering/src/
make[2]: Entering directory 
'/d/temp/RtmpYJkDTJ/R.INSTALL316dc7c0f48e6/MixAll/inst/projects/Clustering/src'
g++ -std=gnu++17  -I"D:/RCompile/recent/R/include" -DNDEBUG `D:/RCompile/recent/R/bin/Rscript -e 
"rtkore:::CppFlags()"`  -I'D:/RCompile/CRANpkg/lib/4.4/Rcpp/include' 
-I'D:/RCompile/CRANpkg/lib/4.4/rtkore/include'   -I"d:/rtools43/x86_64-w64-mingw32.static.posix/include"
`D:/RCompile/recent/R/bin/Rscript -e "rtkore:::CxxFlags()"` -I../inst/projects/ -I../inst/include/ -fopenmp   
-pedantic -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -I../../../projects/ -I../../../include/ 
STK_CategoricalParameters.cpp -c -o ../../../bin/STK_CategoricalParameters.o
/bin/sh: line 1: /x86_64-w64-mingw32.static.posix/bin/g++: Bad address
make[2]: *** [makefile:54: ../../../bin/STK_CategoricalParameters.o] Error 126

RTools uses Cygwin features to emulate the presence of certain virtual
paths; /x86_64-w64-mingw32.static.posix/bin/g++ actually exists and is
transparently mapped to
d:/rtools43/x86_64-w64-mingw32.static.posix/bin/g++.exe:

User@WINMACHINE MSYS ~
$ /x86_64-w64-mingw32.static.posix/bin/g++ --version
g++.exe (GCC) 12.2.0

The "Bad address" here means that /bin/sh got an EFAULT while trying to
launch g++.exe:
https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010223.html

Unless there is something extremely weird in the command line arguments
returned by Rscript -e "rtkore:::CxxFlags()" that causes the process to
fail to launch (in my opinion, very unlikely, but can you print them
from your compilation process just in case?), I would be looking for
problems elsewhere.

In particular, the problem cannot be in having rtkore installed that is
one version too old, because you only changed Makevars in that version,
and your package MixAll doesn't use the Makevars from a different
source package.



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

Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-12 Thread Serge 

Hello Duncan,

Yes, you're right, I'll do that !
Serge

Le 12/01/2024 à 19:47, Duncan Murdoch a écrit :
I don't know if you can find out which rtkore version was installed, but your package should work 
with any rtkore version if you haven't declared a dependency on a particular version.  So the 
simplest thing is just to declare that you depend on "rtkore (>= x.y.z)" where x.y.z has the recent 
fix.


Duncan Murdoch

On 12/01/2024 1:09 p.m., Serge wrote:

I'm the mainteneur of the package MixAll.

This package has a dependency to the package rtkore (whom I'm the mainteneur 
too).
I updated the package rtkore one month ago, fixing a compilation problem on 
windows devel platform.

MixAll has a dependency to rtkore. Thus, I suspect that the error reported 
below is due to
the presence of the old version of rtkore on the pretest infrastructure of the 
CRAN.

My question: is-it possible to know what is the version of rtkore installed on this pretest 
platform ?

(and the https://win-builder.r-project.org/ site too, as I get the same error 
on this site).
Il would certainly save me many tries, my suspicion should be true.

Thanks,
Serge




Dear maintainer,
package MixAll_1.5.4.tar.gz does not pass the incoming checks automatically, please see the 
following pre-tests:
Windows: 


Status: 1 ERROR
Debian: 


Status: 1 NOTE

Last released version's CRAN status: OK: 1, NOTE: 8, WARNING: 2, ERROR: 1
See: 

CRAN Web: 

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on the R-package-devel 
mailing list:

  > 
If you are fairly certain the rejection is a false positive, please reply-all to this message and 
explain.

More details are given in the directory:

  > 


The files will be removed after roughly 7 days.


__
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] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-12 Thread Serge 

Hello Ivan,

Here the output of Cxxflags on my local computer

> rtkore::CppFlags()
-DIS_RTKPP_LIB -DSTKUSELAPACK
> rtkore::CxxFlags()
-I/home/iovleff/R/x86_64-pc-linux-gnu-library/4.3/rtkore/include 
-I/home/iovleff/R/x86_64-pc-linux-gnu-library/4.3/rtkore/projects



and here the code of the functions used internally by CxxFlags() (cpp11 is 
FALSE by default)

# Provide compiler flags -- i.e. -I/path/to/RTKpp.h
# @keywords internal
.rtkoreCxxFlags <- function(cpp11)
{
  path1 <- .rtkore.system.file( "include" )
  path2 <- .rtkore.system.file( "projects" )
  if (.Platform$OS.type=="windows")
  {
path1 <- .asBuildPath(path1);
path2 <- .asBuildPath(path2);
  }
  paste("-I", path1, " -I", path2, if (cpp11) " -std=c++11 " else "", sep="")
}
###
# Adapted from Rcpp package
###
# @rdname rtkoreFlags
# @keywords internal
.asBuildPath <- function(path)
{
  if (.Platform$OS.type == "windows")
  {
path <- normalizePath(path)
if (grepl(' ', path, fixed=TRUE))
  path <- utils::shortPathName(path)
path <- gsub("", "/", path)
  }
  return(path)
}


Le 12/01/2024 à 20:14, Ivan Krylov a écrit :

В Fri, 12 Jan 2024 19:09:29 +0100
Serge  пишет:


I updated the package rtkore one month ago, fixing a compilation
problem on windows devel platform.

MixAll has a dependency to rtkore. Thus, I suspect that the error
reported below is due to the presence of the old version of rtkore on
the pretest infrastructure of the CRAN.


:

/usr/bin/make -C projects/Clustering/src/
make[2]: Entering directory 
'/d/temp/RtmpYJkDTJ/R.INSTALL316dc7c0f48e6/MixAll/inst/projects/Clustering/src'
g++ -std=gnu++17  -I"D:/RCompile/recent/R/include" -DNDEBUG `D:/RCompile/recent/R/bin/Rscript -e 
"rtkore:::CppFlags()"`  -I'D:/RCompile/CRANpkg/lib/4.4/Rcpp/include' 
-I'D:/RCompile/CRANpkg/lib/4.4/rtkore/include'   -I"d:/rtools43/x86_64-w64-mingw32.static.posix/include"
`D:/RCompile/recent/R/bin/Rscript -e "rtkore:::CxxFlags()"` -I../inst/projects/ -I../inst/include/ -fopenmp   
-pedantic -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -I../../../projects/ -I../../../include/ 
STK_CategoricalParameters.cpp -c -o ../../../bin/STK_CategoricalParameters.o
/bin/sh: line 1: /x86_64-w64-mingw32.static.posix/bin/g++: Bad address
make[2]: *** [makefile:54: ../../../bin/STK_CategoricalParameters.o] Error 126

RTools uses Cygwin features to emulate the presence of certain virtual
paths; /x86_64-w64-mingw32.static.posix/bin/g++ actually exists and is
transparently mapped to
d:/rtools43/x86_64-w64-mingw32.static.posix/bin/g++.exe:

User@WINMACHINE MSYS ~
$ /x86_64-w64-mingw32.static.posix/bin/g++ --version
g++.exe (GCC) 12.2.0

The "Bad address" here means that /bin/sh got an EFAULT while trying to
launch g++.exe:
https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010223.html

Unless there is something extremely weird in the command line arguments
returned by Rscript -e "rtkore:::CxxFlags()" that causes the process to
fail to launch (in my opinion, very unlikely, but can you print them
from your compilation process just in case?), I would be looking for
problems elsewhere.

In particular, the problem cannot be in having rtkore installed that is
one version too old, because you only changed Makevars in that version,
and your package MixAll doesn't use the Makevars from a different
source package.



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

Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-12 Thread Ivan Krylov via R-package-devel 
В Fri, 12 Jan 2024 19:09:29 +0100
Serge  пишет:

> I updated the package rtkore one month ago, fixing a compilation
> problem on windows devel platform.
> 
> MixAll has a dependency to rtkore. Thus, I suspect that the error
> reported below is due to the presence of the old version of rtkore on
> the pretest infrastructure of the CRAN.

:

/usr/bin/make -C projects/Clustering/src/
make[2]: Entering directory 
'/d/temp/RtmpYJkDTJ/R.INSTALL316dc7c0f48e6/MixAll/inst/projects/Clustering/src'
g++ -std=gnu++17  -I"D:/RCompile/recent/R/include" -DNDEBUG 
`D:/RCompile/recent/R/bin/Rscript -e "rtkore:::CppFlags()"`  
-I'D:/RCompile/CRANpkg/lib/4.4/Rcpp/include' 
-I'D:/RCompile/CRANpkg/lib/4.4/rtkore/include'   
-I"d:/rtools43/x86_64-w64-mingw32.static.posix/include"
`D:/RCompile/recent/R/bin/Rscript -e "rtkore:::CxxFlags()"` -I../inst/projects/ 
-I../inst/include/ -fopenmp   -pedantic -O2 -Wall  -mfpmath=sse -msse2 
-mstackrealign  -I../../../projects/ -I../../../include/ 
STK_CategoricalParameters.cpp -c -o ../../../bin/STK_CategoricalParameters.o
/bin/sh: line 1: /x86_64-w64-mingw32.static.posix/bin/g++: Bad address
make[2]: *** [makefile:54: ../../../bin/STK_CategoricalParameters.o] Error 126

RTools uses Cygwin features to emulate the presence of certain virtual
paths; /x86_64-w64-mingw32.static.posix/bin/g++ actually exists and is
transparently mapped to
d:/rtools43/x86_64-w64-mingw32.static.posix/bin/g++.exe:

User@WINMACHINE MSYS ~
$ /x86_64-w64-mingw32.static.posix/bin/g++ --version
g++.exe (GCC) 12.2.0

The "Bad address" here means that /bin/sh got an EFAULT while trying to
launch g++.exe:
https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010223.html

Unless there is something extremely weird in the command line arguments
returned by Rscript -e "rtkore:::CxxFlags()" that causes the process to
fail to launch (in my opinion, very unlikely, but can you print them
from your compilation process just in case?), I would be looking for
problems elsewhere.

In particular, the problem cannot be in having rtkore installed that is
one version too old, because you only changed Makevars in that version,
and your package MixAll doesn't use the Makevars from a different
source package.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure

2024-01-12 Thread Duncan Murdoch 
I don't know if you can find out which rtkore version was installed, but 
your package should work with any rtkore version if you haven't declared 
a dependency on a particular version.  So the simplest thing is just to 
declare that you depend on "rtkore (>= x.y.z)" where x.y.z has the 
recent fix.


Duncan Murdoch

On 12/01/2024 1:09 p.m., Serge wrote:

I'm the mainteneur of the package MixAll.

This package has a dependency to the package rtkore (whom I'm the mainteneur 
too).
I updated the package rtkore one month ago, fixing a compilation problem on 
windows devel platform.

MixAll has a dependency to rtkore. Thus, I suspect that the error reported 
below is due to
the presence of the old version of rtkore on the pretest infrastructure of the 
CRAN.

My question: is-it possible to know what is the version of rtkore installed on 
this pretest platform ?
(and the https://win-builder.r-project.org/ site too, as I get the same error 
on this site).
Il would certainly save me many tries, my suspicion should be true.

Thanks,
Serge




Dear maintainer,
  
package MixAll_1.5.4.tar.gz does not pass the incoming checks automatically, please see the following pre-tests:

Windows: 

Status: 1 ERROR
Debian: 

Status: 1 NOTE

Last released version's CRAN status: OK: 1, NOTE: 8, WARNING: 2, ERROR: 1
See: 

CRAN Web: 

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on the 
R-package-devel mailing list:

  > 

If you are fairly certain the rejection is a false positive, please reply-all 
to this message and explain.
   

More details are given in the directory:

  > 


The files will be removed after roughly 7 days.


__
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