[R-pkg-devel] Compiling with more than one compiler in package development
Hello!
I'm not sure if this appeared, so I thought I would try again. I am
building a package on a RedHat supercomputer, using the gcc/gfortran and
the accompanying mpi (MPICH) compilers. Here is the Makefile:
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
all: rmpigFortr.so tria.so
rmpigFortr.so:
mpifort -fPIC -c rmpigFortr.f90 -ormpigFortr.o
mpifort -shared rmpigFortr.o -o rmpigFortr.so
tria.so:
gfortran -m64 -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexcep\
tions -fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches \
-m64 -mtune=generic -c tria.f90 -o tria.o
gfortran -m64 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o tria.so
tria.o\
-L/usr/lib64/R/lib -lR
Here is the NAMESPACE:
# Generated by roxygen2: fake comment so roxygen2 overwrites silently.
exportPattern("^[^\\.]")
useDynLib(rmpigFortr)
useDynLib(tria)
When I build, check, and install the package, it seems to be fine.
However, I have an R function that calls that "tria" Fortran subroutine.
Here are the results:
> library(rmpigFortr)
> za <- tri(n=1000)
Error in .Fortran("tria", as.single(y), as.integer(n)) :
"tria" not resolved from current namespace (rmpigFortr)
>
But if I type in the call to .Fortran myself, it works.
Any idea what I might be doing wrong, please?
Thanks in advance,
Sincerely,
Erin
--
Erin Hodgess
Associate Professor
Department of Mathematical and Statistics
University of Houston - Downtown
mailto: erinm.hodg...@gmail.com
[[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] multithreading in packages
Have you thought about using C or c++, please? Also, there are packages called pbdDMAT from Drew Schmidt at U of Tenn which might help. On Sat, Oct 9, 2021 at 8:39 AM Vladimir Dergachev wrote: > > > On Sat, 9 Oct 2021, Ivan Krylov wrote: > > > В Thu, 7 Oct 2021 21:58:08 -0400 (EDT) > > Vladimir Dergachev пишет: > > > >>* My understanding from reading documentation and source code is > >> that there is no dedicated support in R yet, but there are packages > >> that use multithreading. Are there any plans for multithreading > >> support in future R versions ? > > > > Shared memory multithreading is hard to get right in a memory-safe > > language (e.g. R), but there's the parallel package, which is a part of > > base R, which offers process-based parallelism and may run your code on > > multiple machines at the same time. There's no communication _between_ > > these machines, though. (But I think there's an MPI package on CRAN.) > > Well, the way I planned to use multitheading is to speedup processing of > very large vectors, so one does not have to wait seconds for the command > to return. Same could be done for many built-in R primitives. > > > > >>* pthread or openmp ? I am particularly concerned about > >> interaction with other packages. I have seen that using pthread and > >> openmp libraries simultaneously can result in incorrectly pinned > >> threads. > > > > pthreads-based code could be harder to run on Windows (which is a > > first-class platform for R, expected to be supported by most packages). > > Gábor Csárdi pointed out that R is compiled with mingw on Windows and > has pthread support - something I did not know either. > > > OpenMP should be cross-platform, but Apple compilers are sometimes > > lacking; the latest Apple likely has been solved since I've heard about > > it. If your problem can be made embarrassingly parallel, you're welcome > > to use the parallel package. > > I used parallel before, it is very nice, but R-level only. I am looking > for something to speedup response of individual package functions so they > themselves can be used of part of more complicated code. > > > > >>* control of maximum number of threads. One can default to openmp > >> environment variable, but these might vary between openmp > >> implementations. > > > > Moreover, CRAN-facing tests aren't allowed to consume more than 200% > > CPU, so it's a good idea to leave the number of workers in control of > > the user. According to a reference guide I got from openmp.org, OpenMP > > implementations are expected to understand omp_set_num_threads() and > > the OMP_NUM_THREADS environment variable. > > Oh, this would never be run through CRAN tests, it is meant for data that > is too big for CRAN. > > I seem to remember that the Intel compiler used a different environmental > variable, but it could be this was fixed since the last time I used it. > > best > > Vladimir Dergachev > > > > > -- > > Best regards, > > Ivan > > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[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] multithreading in packages
Yes it does use MPI. You can get the pbd from GitHub, as a backup. Thanks On Sat, Oct 9, 2021 at 2:23 PM Vladimir Dergachev wrote: > > > On Sat, 9 Oct 2021, Erin Hodgess wrote: > > > Have you thought about using C or c++, please? > > Yes, indeed, the core of the package is written in C, with some C++ for > sorting (which turned out to be rather interesting). > > Beyound writing optimized C there are two ways to speed up execution on a > single computer - multithreading and vector instructions. > > Multithreading is easier here, because only one or two libraries are > needed (libgomp or pthread) and because it is often hard to vectorize > operations like sorting, hashing and the like. > > Also, to use vector instructions to full potential one typically needs a > fair bit of black magic which is unlikely to pass CRAN tests. I am having > enough trouble as it is getting a simple flexible array past address > sanitizers. > > > Also, there are packages called pbdDMAT from Drew Schmidt at U of Tenn > which might help. > > Great, thanks for pointing this out ! Looks like pbdDMAT uses mpi. > > Also, it appears this package was removed from CRAN for failing to compile > on macs, which seems rather unfair - I don't know of any clusters running > mac os. > > Vladimir Dergachev -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[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] OpenCL R packages on CRAN
Hello! What about using WSL on Windows, please? Would that help? Thank you, Sincerely, Erin On Mon, Mar 13, 2023 at 5:25 AM Uwe Ligges wrote: > > > On 13.03.2023 11:43, quirin stier wrote: > > Hi, > > > > I would like to ask what the current situation is regarding R packages > > for computations on the GPU. There are no more official CRAN packages > > using CUDA or OpenCL as foundation. There are only packages providing > > either access to OpenCL, tensorflow or similar and packages using > > directives in C++ via OpenMP. > > > > My aim is to provide an R package using OpenCL. However, as far as I > > know, such package would not run in Windows. Does CRAN accept packages > > which are not compatible with every os? > > CRAN asks for cross plattform code if possible. In some situations where > it is not possible to provide cross plattform code, CRAN also accepts > code that works for many (but not all) plattforms. > > OpenCL and Windows: Why would a package using OpenCL not work on Windows? > We may have difficulties providimg binaries of the package (and checking > it) as corresponding graphics hardware is not available on the > build/check machines, but if possible you shopudl support that users > with the required hardware can compile the package from sources on > Windows, too. > > Best, > Uwe Ligges > > __________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[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] is Fortran write still strictly forbidden?
Hi Jisca: I have used the write successfully. I’m not sure if this matters or not, but I am using WSL 2 with Ubuntu 22.04 installed. It works fine with R => 4.0. Hope this helps. Sincerely, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Wed, May 8, 2024 at 6:49 PM Jisca Huisman wrote: > Hello, > > I like to use write() in Fortran code to combine text with some integers > & doubles, to pass runtime information to R in a way that is prettier > and more legible than with intpr() & dblepr(). In the past any calls to > write() were strictly forbidden in Fortran code, as apparently it messed > something up internally (I cannot recall the details). But from 'writing > R extensions' it seems that there have been quite a few changes with > respect to support for Fortran code, and it currently reads: > > > 6.5.1 Printing from Fortran > > On many systems Fortran|write|and|print|statements can be used, but the > output may not interleave well with that of C, and may be invisible > onGUIinterfaces. They are not portable and best avoided. > > > To be more specific, would the subroutine below be allowed? Is it needed > to declare R >= 4.0 (?) in the package DESCRIPTION (& then use labelpr() > instead of intpr() ?) Is there an alternative without write() to get the > same result? > > > subroutine Rprint_pretty(iter, x) > integer, intent(IN) :: iter > double precision, intent(IN) :: x > integer :: date_time_values(8), nchar, IntDummy(0) > character(len=8) :: time_now > character(len=200) :: msg_to_R > > call date_and_time(VALUES=date_time_values) > write(time_now, '(i2.2,":",i2.2,":",i2.2)') date_time_values(5:7) > write(msg_to_R, '(a8, " i: ", i5, " value: ", f8.2)') time_now, > iter, x > > nchar = len(trim(msg_to_R)) > call intpr(trim(msg_to_R), nchar, IntDummy, 0) > >end subroutine Rprint_pretty > > > Thanks! > > > [[alternative HTML version deleted]] > > __ > 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
[R-pkg-devel] trouble with R check
Hello! I'm working with R-3.4.3 and when I run R CMD check rmpiFort_0.0.0.9000.tar.gz, here is the output file. * installing *source* package ‘rmpiFort’ ... ** libs ** arch - make: Nothing to be done for `all'. installing to /home/hodgess/R-3.4.3/bin/rmpiFort.Rcheck/rmpiFort/libs ** R ** preparing package for lazy loading Error : package or namespace load failed for ‘rmpiFort’ in loadNamespace(packag\ e, lib.loc): cyclic namespace dependency detected when loading ‘rmpiFort’, already loading \ ‘rmpiFort’ Error : unable to load R code in package ‘rmpiFort’ ERROR: lazy loading failed for package ‘rmpiFort’ * removing ‘/home/hodgess/R-3.4.3/bin/rmpiFort.Rcheck/rmpiFort’ This is done on the Bridges Supercomputer at the Pittsburgh Supercomputing Center. Thanks, Erin PS. OS is Centos 6. -- Erin Hodgess Associate Professor Department of Mathematical and Statistics University of Houston - Downtown mailto: erinm.hodg...@gmail.com [[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] trouble with R check
Hi Duncan
That was exactly it. Thank you very much
Erin
On Thu, May 31, 2018 at 7:50 AM, Duncan Murdoch
wrote:
> On 31/05/2018 8:35 AM, Erin Hodgess wrote:
>
>> Hello!
>>
>>
>> I'm working with R-3.4.3 and when I run R CMD check
>> rmpiFort_0.0.0.9000.tar.gz, here is the output file.
>>
>>
>> * installing *source* package ‘rmpiFort’ ...
>>
>> ** libs
>>
>> ** arch -
>>
>> make: Nothing to be done for `all'.
>>
>> installing to /home/hodgess/R-3.4.3/bin/rmpiFort.Rcheck/rmpiFort/libs
>>
>> ** R
>>
>> ** preparing package for lazy loading
>>
>> Error : package or namespace load failed for ‘rmpiFort’ in
>> loadNamespace(packag\
>>
>> e, lib.loc):
>>
>> cyclic namespace dependency detected when loading ‘rmpiFort’, already
>> loading \
>>
>> ‘rmpiFort’
>>
>> Error : unable to load R code in package ‘rmpiFort’
>>
>> ERROR: lazy loading failed for package ‘rmpiFort’
>>
>> * removing ‘/home/hodgess/R-3.4.3/bin/rmpiFort.Rcheck/rmpiFort’
>>
>
> Sounds as though something in the package says it depends on itself.
> Possibilities off the top of my head:
>
> You have Depends: rmpiFort or Imports: rmpiFort (or even Suggests:
> rmpiFort, or LinkingTo: rmpiFort) in your DESCRIPTION file.
>
> You have importFrom(rmpiFort, ...) or import(rmpiFort) in your NAMESPACE
> file.
>
> You have requireNamespace("rmpiFort") (or require("rmpiFort"), or
> library("rmpiFort")) in your R source.
>
> Duncan Murdoch
>
--
Erin Hodgess
Associate Professor
Department of Mathematical and Statistics
University of Houston - Downtown
mailto: erinm.hodg...@gmail.com
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] compiling a Windows package with the PGI compiler
Hello! I am building a new package with source code that requires the Portland group compiler. How would I go about building the package with this compiler rather than gfortran, please? Thank you in advance. Sincerely, Erin PS. Windows 10, and R-3.5.1. Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Making adjustments to the R CMD check/install commands
Hello! I'm building a package on Windows 10 which uses the PGI Fortran compiler. I have a Makefile set up in the src directory, and when I run "make all", the subroutines compile beautifully. Now I want to create my package. When I run R CMD check, naturally, gfortran is called. Is there a way that I can direct the check function to just use the make/Makefile, please? Or am I out of luck, please? (highly probable) Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[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] Making adjustments to the R CMD check/install commands
Thank you, Kevin! I put together the Makevars file: PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) FC=c:/progra~1/PGICE/win64/18.4/bin/pgf90 SAFE_FFLAGS="-Lc:/progra~1/PGICE/win64/18.4/lib/pgf90.dll -Lc:/progra~1/PGICE/win64/18.4/lib/pgc14.dll" rmpiFort.obj: rmpiFort.f90 $(FC) $(SAFE_FFLAGS) -Mmpi=msmpi -c rmpiFort.f90 -o rmpiFort.obj rmpiFort.dll: rmpiFort.obj $(FC) $(SAFE_FFLAGS) rmpiFort.obj -Mmpi=msmpi -Mmakedll -o rmpiFort.dll But when I run R CMD check, the 00install file shows that the gfortran compile is used, rather than the PGI compiler: * installing *source* package 'rmpiFort' ...^M ** libs^M ^M *** arch - i386^M C:/progra~1/R/R-35~1.1/share/make/winshlib.mk:13: warning: overriding commands for target `rmpiFort.dll' Makevars:10: warning: ignoring old commands for target `rmpiFort.dll' c:/Rtools/mingw_32/bin/gfortran -O2 -msse2 -mfpmath=sse -Mmpi=msmpi -c rmpiFort.f90 -o rmpiFort.obj gfortran.exe: error: unrecognized command line option '-Mmpi=msmpi'^M make: *** [rmpiFort.obj] Error 1 ERROR: compilation failed for package 'rmpiFort'^M * removing 'C:/Users/erinm/rmpiFort.Rcheck/rmpiFort'^M In R CMD INSTALL^M So I'm still puzzled. Any help much appreciated. Sincerely, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Mon, Aug 27, 2018 at 2:29 PM Kevin Ushey wrote: > Hi Erin, > > The R extensions manual should be helpful here -- in particular, see the > sections on the 'src/Makevars' file and configuration of the Fortran > compiler: > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars > > In particular, in your 'src/Makevars' file, you'll likely want to set the > FC variable to choose the Fortran compiler, and FCFLAGS to choose the > appropriate compilation flags. As an example, you can see how one might set > these flags to compile code with the address sanitizer active: > > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Address-Sanitizer > > (Note that this example uses the user-level '~/.R/Makevars' file rather > than the package-level 'src/Makevars' file, but the crux is the same) > > Hope this gets you on the right track, > Kevin > > On Mon, Aug 27, 2018 at 1:15 PM Erin Hodgess > wrote: > >> Hello! >> >> I'm building a package on Windows 10 which uses the PGI Fortran compiler. >> I have a Makefile set up in the src directory, and when I run "make all", >> the subroutines compile beautifully. >> >> Now I want to create my package. When I run R CMD check, naturally, >> gfortran is called. Is there a way that I can direct the check function >> to >> just use the make/Makefile, please? >> >> Or am I out of luck, please? (highly probable) >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> [[alternative HTML version deleted]] >> >> __ >> 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] Making adjustments to the R CMD check/install commands
Yay! I got it to work! I used the ~/.R/Makevars, and all is well. Thanks again, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Mon, Aug 27, 2018 at 2:29 PM Kevin Ushey wrote: > Hi Erin, > > The R extensions manual should be helpful here -- in particular, see the > sections on the 'src/Makevars' file and configuration of the Fortran > compiler: > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars > > In particular, in your 'src/Makevars' file, you'll likely want to set the > FC variable to choose the Fortran compiler, and FCFLAGS to choose the > appropriate compilation flags. As an example, you can see how one might set > these flags to compile code with the address sanitizer active: > > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Address-Sanitizer > > (Note that this example uses the user-level '~/.R/Makevars' file rather > than the package-level 'src/Makevars' file, but the crux is the same) > > Hope this gets you on the right track, > Kevin > > On Mon, Aug 27, 2018 at 1:15 PM Erin Hodgess > wrote: > >> Hello! >> >> I'm building a package on Windows 10 which uses the PGI Fortran compiler. >> I have a Makefile set up in the src directory, and when I run "make all", >> the subroutines compile beautifully. >> >> Now I want to create my package. When I run R CMD check, naturally, >> gfortran is called. Is there a way that I can direct the check function >> to >> just use the make/Makefile, please? >> >> Or am I out of luck, please? (highly probable) >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> [[alternative HTML version deleted]] >> >> __ >> 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
[R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows
Hello! I'm building a package that needs Openblas for matrix manipulation speed up. I built Openblas on Windows 10. I updated the MkRules.local, src/extra/blas/Makefile.win, etc. Things are working with "make all". However, when I run "make recommended", I have trouble with the Matrix package build. The components of the Cholesky all appear as unreferenced. Has anyone else run into this, please? I'm working with R-3.5.1 source. Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[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] Trying to compile R-3.5.1 with openblas for windows
Hi again! I checked everything, did "make distribution" and the same thing occurred. d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a SuiteSparse_config.o D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to `cholmod_copy_factor' CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to `cholmod_change_factor' CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to `cholmod_factor_to_sparse' CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to `cholmod_free_factor' CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to `cholmod_solve' CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to `cholmod_copy_factor' CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to `cholmod_updown' CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to `cholmod_spsolve' CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to `cholmod_factorize_p' CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to `cholmod_change_factor' CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to `cholmod_copy_factor' CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to `cholmod_copy_factor' CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to `cholmod_free_factor' Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to `cholmod_sparse_to_dense' Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye' Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add' Csparse.o:Csparse.c:(.text+0xd31): undefined reference to `cholmod_free_sparse' Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to `cholmod_copy_sparse' Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to `cholmod_free_sparse' Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy' Does this look familiar, please? Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler wrote: > Try following the directions here. They have worked for me for years. > Please see the comments too. > > https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ > > Hope that helps, > > Avi > > On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess > wrote: > >> Hello! >> >> I'm building a package that needs Openblas for matrix manipulation speed >> up. >> >> I built Openblas on Windows 10. I updated the MkRules.local, >> src/extra/blas/Makefile.win, etc. Things are working with "make all". >> >> However, when I run "make recommended", I have trouble with the Matrix >> package build. The components of the Cholesky all appear as unreferenced. >> >> Has anyone else run into this, please? I'm working with R-3.5.1 source. >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > -- > 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] Trying to compile R-3.5.1 with openblas for windows
That is my next thing to try. Thanks for your help! Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Fri, Sep 14, 2018 at 2:46 PM Avraham Adler wrote: > No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS > recently. Does it work if you use the vanilla BLAS? > > Avi > > On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess > wrote: > >> Hi again! >> >> I checked everything, did "make distribution" and the same thing occurred. >> >> >> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a >> SuiteSparse_config.o >> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file >> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll >> tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o >> chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o >> dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o >> dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o >> sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack >> -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 >> -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR >> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to >> `cholmod_change_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to >> `cholmod_factor_to_sparse' >> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to >> `cholmod_free_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to >> `cholmod_solve' >> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to >> `cholmod_updown' >> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to >> `cholmod_spsolve' >> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to >> `cholmod_factorize_p' >> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to >> `cholmod_change_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to >> `cholmod_free_factor' >> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to >> `cholmod_sparse_to_dense' >> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye' >> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add' >> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to >> `cholmod_free_sparse' >> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to >> `cholmod_copy_sparse' >> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to >> `cholmod_free_sparse' >> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy' >> >> Does this look familiar, please? >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> >> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler >> wrote: >> >>> Try following the directions here. They have worked for me for years. >>> Please see the comments too. >>> >>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ >>> >>> Hope that helps, >>> >>> Avi >>> >>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess >>> wrote: >>> >>>> Hello! >>>> >>>> I'm building a package that needs Openblas for matrix manipulation >>>> speed up. >>>> >>>> I built Openblas on Windows 10. I updated the MkRules.local, >>>> src/extra/blas/Makefile.win, etc. Things are working with "make all". >>>> >>>> However, when I run "make recommended", I have trouble with the Matrix >>>> package build. The components of the Cholesky all appear as >>>> unreferenced. >>>> >>>> Has anyone else run into this, please? I'm working with R-3.5.1 source. >>>> >>>> Thanks, >>>> Erin >>>> >>>> Erin Hodgess, PhD >>>> mailto: erinm.hodg...@gmail.com >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> __ >>>> R-package-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>> >>> -- >>> 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] Trying to compile R-3.5.1 with openblas for windows
I have a snag on regular BLAS as well. I feel better about the Open BLAS On Fri, Sep 14, 2018 at 2:47 PM Erin Hodgess wrote: > That is my next thing to try. Thanks for your help! > > > Erin Hodgess, PhD > mailto: erinm.hodg...@gmail.com > > > On Fri, Sep 14, 2018 at 2:46 PM Avraham Adler > wrote: > >> No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS >> recently. Does it work if you use the vanilla BLAS? >> >> Avi >> >> On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess >> wrote: >> >>> Hi again! >>> >>> I checked everything, did "make distribution" and the same thing >>> occurred. >>> >>> >>> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a >>> SuiteSparse_config.o >>> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file >>> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll >>> tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o >>> chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o >>> dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o >>> dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o >>> sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack >>> -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 >>> -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR >>> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to >>> `cholmod_copy_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to >>> `cholmod_change_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to >>> `cholmod_factor_to_sparse' >>> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to >>> `cholmod_free_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to >>> `cholmod_solve' >>> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to >>> `cholmod_copy_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to >>> `cholmod_updown' >>> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to >>> `cholmod_spsolve' >>> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to >>> `cholmod_factorize_p' >>> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to >>> `cholmod_change_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to >>> `cholmod_copy_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to >>> `cholmod_copy_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to >>> `cholmod_free_factor' >>> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to >>> `cholmod_sparse_to_dense' >>> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye' >>> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add' >>> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to >>> `cholmod_free_sparse' >>> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to >>> `cholmod_copy_sparse' >>> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to >>> `cholmod_free_sparse' >>> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy' >>> >>> Does this look familiar, please? >>> >>> Thanks, >>> Erin >>> >>> Erin Hodgess, PhD >>> mailto: erinm.hodg...@gmail.com >>> >>> >>> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler >>> wrote: >>> >>>> Try following the directions here. They have worked for me for years. >>>> Please see the comments too. >>>> >>>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ >>>> >>>> Hope that helps, >>>> >>>> Avi >>>> >>>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess >>>> wrote: >>>> >>>>> Hello! >>>>> >>>>> I'm building a package that needs Openblas for matrix manipulation >>>>> speed up. >>>>> >>>>> I built Openblas on Windows 10. I updated the MkRules.local, >>>>> src/extra/blas/Makefile.win, etc. Things are working with "make all". >>>>> >>>>> However, when I run "make recommended", I have trouble with the Matrix >>>>> package build. The components of the Cholesky all appear as >>>>> unreferenced. >>>>> >>>>> Has anyone else run into this, please? I'm working with R-3.5.1 >>>>> source. >>>>> >>>>> Thanks, >>>>> Erin >>>>> >>>>> Erin Hodgess, PhD >>>>> mailto: erinm.hodg...@gmail.com >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> __ >>>>> R-package-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>>> >>>> -- >>>> Sent from Gmail Mobile >>>> >>> -- >> Sent from Gmail Mobile >> > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[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] Trying to compile R-3.5.1 with openblas for windows
Finally got Openblas installed! The speed up is amazing! Thanks for your help and patience. Sincerely, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Fri, Sep 14, 2018 at 2:46 PM Avraham Adler wrote: > No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS > recently. Does it work if you use the vanilla BLAS? > > Avi > > On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess > wrote: > >> Hi again! >> >> I checked everything, did "make distribution" and the same thing occurred. >> >> >> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a >> SuiteSparse_config.o >> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file >> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll >> tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o >> chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o >> dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o >> dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o >> sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack >> -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 >> -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR >> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to >> `cholmod_change_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to >> `cholmod_factor_to_sparse' >> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to >> `cholmod_free_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to >> `cholmod_solve' >> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to >> `cholmod_updown' >> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to >> `cholmod_spsolve' >> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to >> `cholmod_factorize_p' >> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to >> `cholmod_change_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to >> `cholmod_free_factor' >> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to >> `cholmod_sparse_to_dense' >> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye' >> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add' >> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to >> `cholmod_free_sparse' >> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to >> `cholmod_copy_sparse' >> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to >> `cholmod_free_sparse' >> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy' >> >> Does this look familiar, please? >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> >> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler >> wrote: >> >>> Try following the directions here. They have worked for me for years. >>> Please see the comments too. >>> >>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ >>> >>> Hope that helps, >>> >>> Avi >>> >>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess >>> wrote: >>> >>>> Hello! >>>> >>>> I'm building a package that needs Openblas for matrix manipulation >>>> speed up. >>>> >>>> I built Openblas on Windows 10. I updated the MkRules.local, >>>> src/extra/blas/Makefile.win, etc. Things are working with "make all". >>>> >>>> However, when I run "make recommended", I have trouble with the Matrix >>>> package build. The components of the Cholesky all appear as >>>> unreferenced. >>>> >>>> Has anyone else run into this, please? I'm working with R-3.5.1 source. >>>> >>>> Thanks, >>>> Erin >>>> >>>> Erin Hodgess, PhD >>>> mailto: erinm.hodg...@gmail.com >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> __ >>>> R-package-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>> >>> -- >>> 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] Using FORTRAN libraries and compiler options
Hello! Have you tried compiling with the -lblas -llapack options, please? Then you can use the appropriate subroutine. Thanks, Erin On Mon, Nov 11, 2019 at 9:40 AM Rampal S. Etienne wrote: > Hello, > > I am using FORTRAN code with the deSolve package. However, the code > still runs slowly. Googling tells me that there are two options to speed > up my code: > > 1. Compile with option -O3 > > 2. Use the library dgemm. > > I understand that this can be set in makevars. However, as I have > limited experience with FORTRAN (never loaded libraries or set compiling > options), I was wondering whether anyone can give me a hint on how to > set this. I have just a single FORTRAN file (with multiple subroutines). > > Cheers, Rampal > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Hello everyone:
I have built the latest version of the OpenBLAS on my Windows 10 machine.
When I run make distribution in R, everything is fine.
However, when I run make check all, I get the following error:
C:\newtimeR\R-3.6.3\src\gnuwin32>make check-all
Testing examples for package 'base'
Testing examples for package 'tools'
comparing 'tools-Ex.Rout' to 'tools-Ex.Rout.save' ... OK
Testing examples for package 'utils'
Error: testing 'utils' failed
Execution halted
make[3]: *** [Makefile.win:29: test-Examples-Base] Error 1
make[2]: *** [Makefile.common:185: test-Examples] Error 2
make[1]: *** [Makefile.common:171: test-all-basics] Error 1
make: *** [Makefile:324: check-all] Error 2
And here is the section from the .Rout.fail for utils:
> ## Multibyte characters in strings (in multibyte locales):
> oloc <- Sys.getlocale("LC_CTYPE")
> mbyte.lc <- if(.Platform$OS.type == "windows")
+ "English_United States.28605" else "en_GB.UTF-8"
> try(Sys.setlocale("LC_CTYPE", mbyte.lc))
[1] "English_United States.28605"
> ## Truncation behavior (<-> correct width measurement) for "long"
non-ASCII:
> idx <- c(65313:65338, 65345:65350)
> fwch <- intToUtf8(idx) # full width character string: each has width 2
> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"),
+ c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
c.ch w.ch c.fw w.fw
64 64 32 64
> stopifnot(unname(ncc) == c(64,64, 32, 64))
> ## nchar.max: 1st line needs an increase of 2 in order to see 1 (in
UTF-8!):
> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
Error in strtrim(x.lrg, nchar.max - nc) :
unsupported conversion from 'UTF-8' in codepage 28605
Calls: lapply ... FUN -> str -> str.default -> maybe_truncate -> strtrim
Execution halted
Has anyone run into this before, please?
If I run this line-by-line starting at the "idx <-", things are fine.
I also compiled R from source without the OpenBLAS, and it was fine.
Thanks for any suggestions.
Sincerely,
Erin
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
[[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] Errors in make check in Windows 10 with OpenBLAS
Hi Tomas and others:
Here is the session Info. I also used the str example both without and
with changing the locale.
sI <- sessionInfo()
> str(sI)
List of 10
$ R.version :List of 14
..$ platform : chr "x86_64-w64-mingw32"
..$ arch : chr "x86_64"
..$ os: chr "mingw32"
..$ system: chr "x86_64, mingw32"
..$ status: chr ""
..$ major : chr "3"
..$ minor : chr "6.3"
..$ year : chr "2020"
..$ month : chr "02"
..$ day : chr "29"
..$ svn rev : chr "77875"
..$ language : chr "R"
..$ version.string: chr "R version 3.6.3 (2020-02-29)"
..$ nickname : chr "Holding the Windsock"
$ platform : chr "x86_64-w64-mingw32/x64 (64-bit)"
$ locale: chr "LC_COLLATE=English_United
States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United
States.125"| __truncated__
$ running : chr "Windows 10 x64 (build 18362)"
$ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
$ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
$ loadedOnly:List of 1
..$ compiler:List of 9
.. ..$ Package: chr "compiler"
.. ..$ Version: chr "3.6.3"
.. ..$ Priority : chr "base"
.. ..$ Title : chr "The R Compiler Package"
.. ..$ Author : chr "Luke Tierney "
.. ..$ Maintainer : chr "R Core Team "
.. ..$ Description: chr "Byte code compiler for R."
.. ..$ License: chr "Part of R 3.6.3"
.. ..$ Built : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC; windows"
.. ..- attr(*, "class")= chr "packageDescription"
.. ..- attr(*, "file")= chr
"c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds"
$ matprod : chr "default"
$ BLAS : chr ""
$ LAPACK: chr ""
- attr(*, "class")= chr "sessionInfo"
Running the str example WITHOUT changing the locale:
> ## Truncation behavior (<-> correct width measurement) for "long"
non-ASCII:
> idx <- c(65313:65338, 65345:65350)
> fwch <- intToUtf8(idx) # full width character string: each has width 2
> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"),
+ c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
c.ch w.ch c.fw w.fw
64 64 32 64
> stopifnot(unname(ncc) == c(64,64, 32, 64))
> ## nchar.max: 1st line needs an increase of 2 in order to see 1 (in
UTF-$
> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
chr ""| __truncated__
chr "<"| __truncated__
> invisible(lapply(60:66, function(N) str( ch , nchar.max = N))) # "1 is 1"
he$
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O."| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P."| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._Q._R._S._T._U._V"
>
Running the str example WITH changing the locale:
oloc <- Sys.getlocale("LC_CTYPE")
> mbyte.lc <- if(.Platform$OS.type == "windows")
+ "English_United States.28605" else "en_GB.UTF-8"
> try(Sys.setlocale("LC_CTYPE", mbyte.lc))
[1] "English_United States.28605"
> ## Truncation behavior (<-> correct width measurement) for "long"
non-ASCII:
> idx <- c(65313:65338, 65345:65350)
> fwch <- intToUtf8(idx) # full width character string: each has width 2
> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"),
+ c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
c.ch w.ch c.fw w.fw
64 64 32 64
> stopifnot(unname(ncc) == c(64,64, 32, 64))
> ## nchar.max: 1st line needs an increase of 2 in order to see 1 (in
UTF-$
> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
Error in strtrim(x.lrg, nchar.max - nc) :
unsupported conversion from 'UTF-8' in codepage 28605
> invisible(lapply(60:66, function(N) str( ch , nchar.max = N))) # "1 is 1"
he$
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L.
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
I was wondering if there is a way to either skip the utilities check and continuing, in order to test the other packages, please. Thanks! On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler wrote: > >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes: > > > Hi Tomas and others: > > Here is the session Info. I also used the str example both without > and > > with changing the locale. > > > sI <- sessionInfo() > >> str(sI) > > List of 10 > > $ R.version :List of 14 > > ..$ platform : chr "x86_64-w64-mingw32" > > ..$ arch : chr "x86_64" > > ..$ os: chr "mingw32" > > ..$ system: chr "x86_64, mingw32" > > ..$ status: chr "" > > ..$ major : chr "3" > > ..$ minor : chr "6.3" > > ..$ year : chr "2020" > > ..$ month : chr "02" > > ..$ day : chr "29" > > ..$ svn rev : chr "77875" > > ..$ language : chr "R" > > ..$ version.string: chr "R version 3.6.3 (2020-02-29)" > > ..$ nickname : chr "Holding the Windsock" > > $ platform : chr "x86_64-w64-mingw32/x64 (64-bit)" > > $ locale: chr "LC_COLLATE=English_United > > States.1252;LC_CTYPE=English_United > States.1252;LC_MONETARY=English_United > > States.125"| __truncated__ > > $ running : chr "Windows 10 x64 (build 18362)" > > $ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection" > > $ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ... > > $ loadedOnly:List of 1 > > ..$ compiler:List of 9 > > .. ..$ Package: chr "compiler" > > .. ..$ Version: chr "3.6.3" > > .. ..$ Priority : chr "base" > > .. ..$ Title : chr "The R Compiler Package" > > .. ..$ Author : chr "Luke Tierney " > > .. ..$ Maintainer : chr "R Core Team " > > .. ..$ Description: chr "Byte code compiler for R." > > .. ..$ License: chr "Part of R 3.6.3" > > .. ..$ Built : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC; > windows" > > .. ..- attr(*, "class")= chr "packageDescription" > > .. ..- attr(*, "file")= chr > > "c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds" > > $ matprod : chr "default" > > $ BLAS : chr "" > > $ LAPACK: chr "" > > - attr(*, "class")= chr "sessionInfo" > > > > Running the str example WITHOUT changing the locale: > >> ## Truncation behavior (<-> correct width measurement) for "long" > > non-ASCII: > >> idx <- c(65313:65338, 65345:65350) > >> fwch <- intToUtf8(idx) # full width character string: each has > width 2 > >> ch <- strtrim(paste(LETTERS, collapse="._"), 64) > >> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"), > > + c.fw = nchar(fwch), w.fw = nchar(fwch, "w"))) > > c.ch w.ch c.fw w.fw > > 64 64 32 64 > >> stopifnot(unname(ncc) == c(64,64, 32, 64)) > >> ## nchar.max: 1st line needs an increase of 2 in order to see 1 > (in > > UTF-$ > >> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N))) > > chr " > chr " > chr " > chr " > chr " > chr ""| > __truncated__ > > chr "<"| > __truncated__ > >> invisible(lapply(60:66, function(N) str( ch , nchar.max = N))) # "1 > is 1" > > he$ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O."| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._"| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P"| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P."| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._"| > __truncated__ >
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Great idea!
Thanks
On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
wrote:
> Hi Erin,
>
> when you are building from sources, you can always uncomment the example
> in str.Rd. But it would be good first to find out why it is failing on your
> system/build.
>
> Please run the example in Rgui of the official R 3.6.3 build on your
> machine. Does it work there?
>
> Please run the following commands in Rgui of the official R 3.6.3 build on
> the machine and on your custom build. What do you get?
>
> Sys.getlocale()
> enc2native("\uff21")
> enc2native("\u4e2d")
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
> enc2native("\uff21")
> enc2native("\u4e2d")
> extSoftVersion()[c("iconv","BLAS")]
> Thanks,
> Tomas
>
> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>
> I was wondering if there is a way to either skip the utilities check and
> continuing, in order to test the other packages, please.
>
> Thanks!
>
>
> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
> maech...@stat.math.ethz.ch> wrote:
>
>> >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>
>> > Hi Tomas and others:
>> > Here is the session Info. I also used the str example both
>> without and
>> > with changing the locale.
>>
>> > sI <- sessionInfo()
>> >> str(sI)
>> > List of 10
>> > $ R.version :List of 14
>> > ..$ platform : chr "x86_64-w64-mingw32"
>> > ..$ arch : chr "x86_64"
>> > ..$ os: chr "mingw32"
>> > ..$ system: chr "x86_64, mingw32"
>> > ..$ status: chr ""
>> > ..$ major : chr "3"
>> > ..$ minor : chr "6.3"
>> > ..$ year : chr "2020"
>> > ..$ month : chr "02"
>> > ..$ day : chr "29"
>> > ..$ svn rev : chr "77875"
>> > ..$ language : chr "R"
>> > ..$ version.string: chr "R version 3.6.3 (2020-02-29)"
>> > ..$ nickname : chr "Holding the Windsock"
>> > $ platform : chr "x86_64-w64-mingw32/x64 (64-bit)"
>> > $ locale: chr "LC_COLLATE=English_United
>> > States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> > States.125"| __truncated__
>> > $ running : chr "Windows 10 x64 (build 18362)"
>> > $ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
>> > $ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
>> > $ loadedOnly:List of 1
>> > ..$ compiler:List of 9
>> > .. ..$ Package: chr "compiler"
>> > .. ..$ Version: chr "3.6.3"
>> > .. ..$ Priority : chr "base"
>> > .. ..$ Title : chr "The R Compiler Package"
>> > .. ..$ Author : chr "Luke Tierney "
>> > .. ..$ Maintainer : chr "R Core Team "
>> > .. ..$ Description: chr "Byte code compiler for R."
>> > .. ..$ License: chr "Part of R 3.6.3"
>> > .. ..$ Built : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC;
>> windows"
>> > .. ..- attr(*, "class")= chr "packageDescription"
>> > .. ..- attr(*, "file")= chr
>> > "c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds"
>> > $ matprod : chr "default"
>> > $ BLAS : chr ""
>> > $ LAPACK: chr ""
>> > - attr(*, "class")= chr "sessionInfo"
>>
>>
>> > Running the str example WITHOUT changing the locale:
>> >> ## Truncation behavior (<-> correct width measurement) for "long"
>> > non-ASCII:
>> >> idx <- c(65313:65338, 65345:65350)
>> >> fwch <- intToUtf8(idx) # full width character string: each has
>> width 2
>> >> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
>> >> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"),
>> > + c.fw = nchar(fwch), w.fw = nchar
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Here are the results.
Looks like enc2native and the iconv settings are different.
> #output from custom build
> Sys.getlocale()
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> enc2native("\uff21")
[1] ""
> enc2native("\u4e2d")
[1] ""
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
[1] "English_United States.28605"
> enc2native("\uff21")
Error: unsupported conversion from 'UTF-8' in codepage 28605
> enc2native("\u4e2d")
Error: unsupported conversion from 'UTF-8' in codepage 28605
> extSoftVersion()[c("iconv","BLAS")]
iconvBLAS
"GNU libiconv 1.14" ""
> #output from regular build
> Sys.getlocale()
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> enc2native("\uff21")
[1] "A"
> enc2native("\u4e2d")
[1] ""
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
[1] "English_United States.28605"
> enc2native("\uff21")
[1] "A"
> enc2native("\u4e2d")
[1] ""
> extSoftVersion()[c("iconv","BLAS")]
iconvBLAS
"win_iconv" ""
>
Thanks!
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
wrote:
> Hi Erin,
>
> when you are building from sources, you can always uncomment the example
> in str.Rd. But it would be good first to find out why it is failing on your
> system/build.
>
> Please run the example in Rgui of the official R 3.6.3 build on your
> machine. Does it work there?
>
> Please run the following commands in Rgui of the official R 3.6.3 build on
> the machine and on your custom build. What do you get?
>
> Sys.getlocale()
> enc2native("\uff21")
> enc2native("\u4e2d")
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
> enc2native("\uff21")
> enc2native("\u4e2d")
> extSoftVersion()[c("iconv","BLAS")]
> Thanks,
> Tomas
>
> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>
> I was wondering if there is a way to either skip the utilities check and
> continuing, in order to test the other packages, please.
>
> Thanks!
>
>
> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
> maech...@stat.math.ethz.ch> wrote:
>
>> >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>
>> > Hi Tomas and others:
>> > Here is the session Info. I also used the str example both
>> without and
>> > with changing the locale.
>>
>> > sI <- sessionInfo()
>> >> str(sI)
>> > List of 10
>> > $ R.version :List of 14
>> > ..$ platform : chr "x86_64-w64-mingw32"
>> > ..$ arch : chr "x86_64"
>> > ..$ os: chr "mingw32"
>> > ..$ system: chr "x86_64, mingw32"
>> > ..$ status: chr ""
>> > ..$ major : chr "3"
>> > ..$ minor : chr "6.3"
>> > ..$ year : chr "2020"
>> > ..$ month : chr "02"
>> > ..$ day : chr "29"
>> > ..$ svn rev : chr "77875"
>> > ..$ language : chr "R"
>> > ..$ version.string: chr "R version 3.6.3 (2020-02-29)"
>> > ..$ nickname : chr "Holding the Windsock"
>> > $ platform : chr "x86_64-w64-mingw32/x64 (64-bit)"
>> > $ locale: chr "LC_COLLATE=English_United
>> > States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> > States.125"| __truncated__
>> > $ running : chr "Windows 10 x64 (build 18362)"
>> > $ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
>> > $ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
>> > $ loadedOnly:List of 1
>> > ..$ compiler:List of 9
>> > .. ..$ Package: chr "compiler"
>> > .. .
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
And the example runs just fine on the regular build.
Thanks
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
wrote:
> Hi Erin,
>
> when you are building from sources, you can always uncomment the example
> in str.Rd. But it would be good first to find out why it is failing on your
> system/build.
>
> Please run the example in Rgui of the official R 3.6.3 build on your
> machine. Does it work there?
>
> Please run the following commands in Rgui of the official R 3.6.3 build on
> the machine and on your custom build. What do you get?
>
> Sys.getlocale()
> enc2native("\uff21")
> enc2native("\u4e2d")
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
> enc2native("\uff21")
> enc2native("\u4e2d")
> extSoftVersion()[c("iconv","BLAS")]
> Thanks,
> Tomas
>
> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>
> I was wondering if there is a way to either skip the utilities check and
> continuing, in order to test the other packages, please.
>
> Thanks!
>
>
> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
> maech...@stat.math.ethz.ch> wrote:
>
>> >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>
>> > Hi Tomas and others:
>> > Here is the session Info. I also used the str example both
>> without and
>> > with changing the locale.
>>
>> > sI <- sessionInfo()
>> >> str(sI)
>> > List of 10
>> > $ R.version :List of 14
>> > ..$ platform : chr "x86_64-w64-mingw32"
>> > ..$ arch : chr "x86_64"
>> > ..$ os: chr "mingw32"
>> > ..$ system: chr "x86_64, mingw32"
>> > ..$ status: chr ""
>> > ..$ major : chr "3"
>> > ..$ minor : chr "6.3"
>> > ..$ year : chr "2020"
>> > ..$ month : chr "02"
>> > ..$ day : chr "29"
>> > ..$ svn rev : chr "77875"
>> > ..$ language : chr "R"
>> > ..$ version.string: chr "R version 3.6.3 (2020-02-29)"
>> > ..$ nickname : chr "Holding the Windsock"
>> > $ platform : chr "x86_64-w64-mingw32/x64 (64-bit)"
>> > $ locale: chr "LC_COLLATE=English_United
>> > States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> > States.125"| __truncated__
>> > $ running : chr "Windows 10 x64 (build 18362)"
>> > $ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
>> > $ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
>> > $ loadedOnly:List of 1
>> > ..$ compiler:List of 9
>> > .. ..$ Package: chr "compiler"
>> > .. ..$ Version: chr "3.6.3"
>> > .. ..$ Priority : chr "base"
>> > .. ..$ Title : chr "The R Compiler Package"
>> > .. ..$ Author : chr "Luke Tierney "
>> > .. ..$ Maintainer : chr "R Core Team "
>> > .. ..$ Description: chr "Byte code compiler for R."
>> > .. ..$ License: chr "Part of R 3.6.3"
>> > .. ..$ Built : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC;
>> windows"
>> > .. ..- attr(*, "class")= chr "packageDescription"
>> > .. ..- attr(*, "file")= chr
>> > "c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds"
>> > $ matprod : chr "default"
>> > $ BLAS : chr ""
>> > $ LAPACK: chr ""
>> > - attr(*, "class")= chr "sessionInfo"
>>
>>
>> > Running the str example WITHOUT changing the locale:
>> >> ## Truncation behavior (<-> correct width measurement) for "long"
>> > non-ASCII:
>> >> idx <- c(65313:65338, 65345:65350)
>> >> fwch <- intToUtf8(idx) # full width character string: each has
>> width 2
>> >> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
>> >> (ncc <- c(c.ch = nchar(ch), w.ch = ncha
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Thanks for the explanation!
I will re-run everything.
Sincerely,
Erin
On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera
wrote:
> Thanks, so the problem is that your custom build uses GNU libiconv, which
> does not support codepage 28605. win_iconv, the one shipped with R,
> supports that code page. win_iconv is a wrapper for the Windows API. Unless
> you had a special reason not to, I would just recommend to use win_iconv.
> The "experience" will match the C library conversion calls, which may be
> used directly in some code at some places, and it is most tested as people
> normally use it. Still, the problem is not specific to strtrim, just to the
> example.
>
> Best
>
> Tomas
>
>
> On 3/20/20 3:27 PM, Erin Hodgess wrote:
>
> Here are the results.
>
> Looks like enc2native and the iconv settings are different.
>
>
> > #output from custom build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] ""
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > enc2native("\u4e2d")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > extSoftVersion()[c("iconv","BLAS")]
> iconvBLAS
> "GNU libiconv 1.14" ""
>
>
> > #output from regular build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > extSoftVersion()[c("iconv","BLAS")]
> iconvBLAS
> "win_iconv" ""
> >
>
> Thanks!
>
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
> wrote:
>
>> Hi Erin,
>>
>> when you are building from sources, you can always uncomment the example
>> in str.Rd. But it would be good first to find out why it is failing on your
>> system/build.
>>
>> Please run the example in Rgui of the official R 3.6.3 build on your
>> machine. Does it work there?
>>
>> Please run the following commands in Rgui of the official R 3.6.3 build
>> on the machine and on your custom build. What do you get?
>>
>> Sys.getlocale()
>> enc2native("\uff21")
>> enc2native("\u4e2d")
>> Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> enc2native("\uff21")
>> enc2native("\u4e2d")
>> extSoftVersion()[c("iconv","BLAS")]
>> Thanks,
>> Tomas
>>
>> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>>
>> I was wondering if there is a way to either skip the utilities check and
>> continuing, in order to test the other packages, please.
>>
>> Thanks!
>>
>>
>> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
>> maech...@stat.math.ethz.ch> wrote:
>>
>>> >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>>
>>> > Hi Tomas and others:
>>> > Here is the session Info. I also used the str example both
>>> without and
>>> > with changing the locale.
>>>
>>> > sI <- sessionInfo()
>>> >> str(sI)
>>> > List of 10
>>> > $ R.version :List of 14
>>> > ..$ platform : chr "x86_64-w64-mingw32"
>>> > ..$ arch : chr "x86_64"
>>> > ..$ os: chr "mingw32"
>>> > ..$ system: chr "x86_64, mingw32"
>>> > ..$ status: chr ""
>>> > ..$ major : chr "3"
>>> > ..$ minor
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Hello again.
So I'm trying to find the place where the GNU iconv comes from. However, I
looked at output from both the regular build and the custom, and I'm not
seeing any differences in how win_iconv is generated.
Any suggestions, please?
Custom:
c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
installing zoneinfo
making win_iconv.d from win_iconv.c
c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall -pedantic
-march=native -pipe -c win_iconv.c -o win_iconv.o
c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
win_iconv.o
Regular:
c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
installing zoneinfo
making win_iconv.d from win_iconv.c
c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall -pedantic
-mtune=core2 -c win_iconv.c -o win_iconv.o
c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
win_iconv.o
Just the -march=native -pipe
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera
wrote:
> Thanks, so the problem is that your custom build uses GNU libiconv, which
> does not support codepage 28605. win_iconv, the one shipped with R,
> supports that code page. win_iconv is a wrapper for the Windows API. Unless
> you had a special reason not to, I would just recommend to use win_iconv.
> The "experience" will match the C library conversion calls, which may be
> used directly in some code at some places, and it is most tested as people
> normally use it. Still, the problem is not specific to strtrim, just to the
> example.
>
> Best
> Tomas
>
>
> On 3/20/20 3:27 PM, Erin Hodgess wrote:
>
> Here are the results.
>
> Looks like enc2native and the iconv settings are different.
>
>
> > #output from custom build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] ""
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > enc2native("\u4e2d")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > extSoftVersion()[c("iconv","BLAS")]
> iconvBLAS
> "GNU libiconv 1.14" ""
>
>
> > #output from regular build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > extSoftVersion()[c("iconv","BLAS")]
> iconvBLAS
> "win_iconv" ""
> >
>
> Thanks!
>
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
> wrote:
>
>> Hi Erin,
>>
>> when you are building from sources, you can always uncomment the example
>> in str.Rd. But it would be good first to find out why it is failing on your
>> system/build.
>>
>> Please run the example in Rgui of the official R 3.6.3 build on your
>> machine. Does it work there?
>>
>> Please run the following commands in Rgui of the official R 3.6.3 build
>> on the machine and on your custom build. What do you get?
>>
>> Sys.getlocale()
>> enc2native("\uff21")
>> enc2native("\u4e2d")
>> Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> enc2native("\uff21")
>> enc2native("\u4e2d")
>> extSoftVersion()[c("iconv","BLAS")]
>> Thanks,
>> Tomas
>>
>> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>>
>> I was wondering if there is a way to either skip the utilities check and
>> continuing, in order to test the other packages, please.
>>
>> Thanks!
>>
>>
>> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
>> maech...@stat.math.e
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Thanks!
I searched the output for Riconv but no luck yet.
On Sat, Mar 21, 2020 at 10:29 AM Tomas Kalibera
wrote:
> Maybe the created Riconv.dll is copied over by libiconv at some point
> during your custom build.
>
> Tomas
>
> On 3/21/20 3:58 PM, Erin Hodgess wrote:
>
> Hello again.
>
> So I'm trying to find the place where the GNU iconv comes from. However,
> I looked at output from both the regular build and the custom, and I'm not
> seeing any differences in how win_iconv is generated.
>
> Any suggestions, please?
>
> Custom:
> c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
> installing zoneinfo
> making win_iconv.d from win_iconv.c
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall
> -pedantic -march=native -pipe -c win_iconv.c -o win_iconv.o
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
> win_iconv.o
>
> Regular:
> c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
> installing zoneinfo
> making win_iconv.d from win_iconv.c
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall
> -pedantic -mtune=core2 -c win_iconv.c -o win_iconv.o
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
> win_iconv.o
>
> Just the -march=native -pipe
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera
> wrote:
>
>> Thanks, so the problem is that your custom build uses GNU libiconv, which
>> does not support codepage 28605. win_iconv, the one shipped with R,
>> supports that code page. win_iconv is a wrapper for the Windows API. Unless
>> you had a special reason not to, I would just recommend to use win_iconv.
>> The "experience" will match the C library conversion calls, which may be
>> used directly in some code at some places, and it is most tested as people
>> normally use it. Still, the problem is not specific to strtrim, just to the
>> example.
>>
>> Best
>> Tomas
>>
>>
>> On 3/20/20 3:27 PM, Erin Hodgess wrote:
>>
>> Here are the results.
>>
>> Looks like enc2native and the iconv settings are different.
>>
>>
>> > #output from custom build
>> > Sys.getlocale()
>> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>> > enc2native("\uff21")
>> [1] ""
>> > enc2native("\u4e2d")
>> [1] ""
>> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> [1] "English_United States.28605"
>> > enc2native("\uff21")
>> Error: unsupported conversion from 'UTF-8' in codepage 28605
>> > enc2native("\u4e2d")
>> Error: unsupported conversion from 'UTF-8' in codepage 28605
>> > extSoftVersion()[c("iconv","BLAS")]
>> iconvBLAS
>> "GNU libiconv 1.14" ""
>>
>>
>> > #output from regular build
>> > Sys.getlocale()
>> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>> > enc2native("\uff21")
>> [1] "A"
>> > enc2native("\u4e2d")
>> [1] ""
>> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> [1] "English_United States.28605"
>> > enc2native("\uff21")
>> [1] "A"
>> > enc2native("\u4e2d")
>> [1] ""
>> > extSoftVersion()[c("iconv","BLAS")]
>> iconvBLAS
>> "win_iconv" ""
>> >
>>
>> Thanks!
>>
>>
>> Erin Hodgess, PhD
>> mailto: erinm.hodg...@gmail.com
>>
>>
>> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
>> wrote:
>>
>>> Hi Erin,
>>>
>>> when you are building from sources, you can always uncomment the example
>>> in str.Rd. But it would be good first to find out why it is failing on your
>>> system/build.
>>>
>>> Please run the example in Rgui of the official R 3.6.3 build on your
>>> machine. Does it work there?
>>>
>>> Please run the following commands in Rgui of the official R 3.6.3 build
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Finally figured it out...I was having "path problems"!
I'm all set here.
Thanks so much for your help
Sincerely,
Erin
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
On Sat, Mar 21, 2020 at 10:29 AM Tomas Kalibera
wrote:
> Maybe the created Riconv.dll is copied over by libiconv at some point
> during your custom build.
>
> Tomas
>
> On 3/21/20 3:58 PM, Erin Hodgess wrote:
>
> Hello again.
>
> So I'm trying to find the place where the GNU iconv comes from. However,
> I looked at output from both the regular build and the custom, and I'm not
> seeing any differences in how win_iconv is generated.
>
> Any suggestions, please?
>
> Custom:
> c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
> installing zoneinfo
> making win_iconv.d from win_iconv.c
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall
> -pedantic -march=native -pipe -c win_iconv.c -o win_iconv.o
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
> win_iconv.o
>
> Regular:
> c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
> installing zoneinfo
> making win_iconv.d from win_iconv.c
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall
> -pedantic -mtune=core2 -c win_iconv.c -o win_iconv.o
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
> win_iconv.o
>
> Just the -march=native -pipe
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera
> wrote:
>
>> Thanks, so the problem is that your custom build uses GNU libiconv, which
>> does not support codepage 28605. win_iconv, the one shipped with R,
>> supports that code page. win_iconv is a wrapper for the Windows API. Unless
>> you had a special reason not to, I would just recommend to use win_iconv.
>> The "experience" will match the C library conversion calls, which may be
>> used directly in some code at some places, and it is most tested as people
>> normally use it. Still, the problem is not specific to strtrim, just to the
>> example.
>>
>> Best
>> Tomas
>>
>>
>> On 3/20/20 3:27 PM, Erin Hodgess wrote:
>>
>> Here are the results.
>>
>> Looks like enc2native and the iconv settings are different.
>>
>>
>> > #output from custom build
>> > Sys.getlocale()
>> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>> > enc2native("\uff21")
>> [1] ""
>> > enc2native("\u4e2d")
>> [1] ""
>> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> [1] "English_United States.28605"
>> > enc2native("\uff21")
>> Error: unsupported conversion from 'UTF-8' in codepage 28605
>> > enc2native("\u4e2d")
>> Error: unsupported conversion from 'UTF-8' in codepage 28605
>> > extSoftVersion()[c("iconv","BLAS")]
>> iconvBLAS
>> "GNU libiconv 1.14" ""
>>
>>
>> > #output from regular build
>> > Sys.getlocale()
>> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>> > enc2native("\uff21")
>> [1] "A"
>> > enc2native("\u4e2d")
>> [1] ""
>> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> [1] "English_United States.28605"
>> > enc2native("\uff21")
>> [1] "A"
>> > enc2native("\u4e2d")
>> [1] ""
>> > extSoftVersion()[c("iconv","BLAS")]
>> iconvBLAS
>> "win_iconv" ""
>> >
>>
>> Thanks!
>>
>>
>> Erin Hodgess, PhD
>> mailto: erinm.hodg...@gmail.com
>>
>>
>> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
>> wrote:
>>
>>> Hi Erin,
>>>
>>> when you are building from sources, you can always uncomment the example
>>> in str.Rd. But it would be good first to find out why it is failing on your
>>> system/build.
>>>
>>> Please run the example in Rgui of the official R 3.6.3 build on your
>>> machine. Does it wo
Re: [R-pkg-devel] Fortran with OpenMP on MACOS
I’m sure that you have done this, but did you set a compiler option of -fopenmp, please? Thanks On Tue, Oct 13, 2020 at 9:35 AM Sergio Ibarra-Espinosa wrote: > Dear List, > > I have a package that was archived ( > > https://cran-archive.r-project.org/web/checks/2020/2020-10-07_check_results_vein.html > ) because I could not solve an issue with OpenMP and Fortran on MACOS. > > I have seen that packages with C add precompilation conditions, for > instance: > > > https://github.com/tesujimath/R-OpenMPController/blob/86bd047e8bfdf3c87877336ff8e2d3b69327fe03/src/omp_set_num_threads_ptr.c#L12 > > #ifdef _OPENMP > omp_set_num_threads(*np); > #endif > > So, I tried adding those lines in #ifdef _OPENMP #endif in > fortran, with the flag -cpp and the MACROS recommended by the R EXTS > manual: > > USE_FC_TO_LINK = > PKG_FFLAGS = $(SHLIB_OPENMP_FFLAGS) *-cpp* > PKG_LIBS = $(SHLIB_OPENMP_FFLAGS) > > But with R CMD Check i got the message: > > Non-portable flags in variable 'PKG_FFLAGS': -cpp > > I would be very grateful if someone provides me some guidelines. Thank you > so much > > Best, Sergio > > > *Sergio Ibarra Espinosa* > Postdoc in Atmospheric Sciences, Universidade de São Paulo > > + <++8617643016295>55 11 934 909 778 | +55 11 974 253 791 > <+55+11+974+253+791> | sergio.iba...@usp.br > > www.sergioibarra.blogspot.com | *Skype*: sergio_ibarra1 > <https://mail.google.com/mail/u/0/#SignatureSanitizer_SafeHtmlFilter_> > Rua do Matão, 1226 > <https://www.google.com/maps/search/Rua+do+Mat%C3%A3o,+1226?entry=gmail&source=g> > - Cidade Universitária São Paulo-SP - Brasil - 05508-090 > <http://github.com/ibarraespinosa> > <https://zoom.us/j/6527509021?pwd=VmlXQWliR1JSZGtpS0tJR1A2dUZpZz09> > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
