Re: [R-pkg-devel] Is winbuilder "offline"?
Not that I know, which queue do you mean? Best, Uwe On 19.07.2024 00:45, Rolf Turner wrote: I submitted a package to winbuilder, yesterday. Twice. No response of any sort. Is the system down, for some reason? Anyone know? Ta. cheers, Rolf Turner __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package
Hi All,
I recently became aware of what appears to be some kind of incompatibility
between the Perl distribution that is included in the RTools 4.4 distribution
and my WriteXLS package on CRAN, running R 4.4.1. As far as I can tell, since
the vast majority of the users of my package, which requires Perl, are running
standard Perl installations, that is native OS, Strawberry Perl or Active State
Perl, this appears to be something of a unique issue.
It is not clear to me what the root cause of the problem is, and whether it is
the RTools Perl binary itself and/or any of the other related components that
are included in RTools, if this is specific to RTools, or may be an upstream
issue from MSYS2. Thus, before I think about going down the rabbit hole, I am
wondering if anyone has any intuitive guidance on this issue.
I was also a bit confused by this, as my aging memory recalled that the old
Vanilla Perl had been removed from RTools many years ago circa R 2.x.y, so
presume that there was motivation to reintroduce Perl in recent versions of
RTools.
I have been able to largely replicate the problem on my MacBook Pro, running a
Windows 11 VM under Parallels on macOS 14.5, and confirmed a workaround using a
current Strawberry Perl installation for Windows on the same system.
The initial report was from a user running Windows 10 on a native Intel based
PC, with R 4.4.1 and RTools 4.4 installed, and they reported the following
error:
> WriteXLS::WriteXLS(iris, "test.xlsx", verbose=T)
Creating Temporary Directory for CSV Files:
C:\Users\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS
Creating CSV File: 1.csv
Creating SheetNames.txt
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "en"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
. No such file or
directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
Creating Excel File: C:\Users\Kleinbub\Documents\test.xlsx
Reading: C:\Users\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
The Perl script 'WriteXLSX.pl' failed to run successfully.
Cleaning Up Temporary Files and Directory
The basic workflow steps are that my R code wrapper function writes a CSV file
containing the 'iris' dataframe into a temporary directory, my Perl script then
reads in and parses that CSV file. and creates the Excel file using the
relevant Perl packages included. The 'verbose = TRUE' setting outputs some
additional diagnostic messages.
Note above that there are some warnings regarding locale settings from Perl,
which I could not replicate on my Windows VM, albeit I can replicate the key
error and failure of the Perl script as indicated.
If I run the same test code on my Windows 11 VM system, I get the following,
including the initial testing function, which points to Perl in RTools:
> testPerl()
A system perl installation found in C:\rtools44\usr\bin\perl.exe
The perl modules included with WriteXLS are located in
C:/Users/marcschwartz/AppData/Local/R/win-library/4.4/WriteXLS/Perl
All required Perl modules were found.
> WriteXLS(iris, "test.xlsx")
ERROR: cannot open
C:\Users\MARCSC~1\AppData\Local\Temp\RtmpmKwGGX/WriteXLS/1.csv
. No such file or directory
The Perl script 'WriteXLSX.pl' failed to run successfully.
Note that I do not get the locale warnings, and this does not appear to be a
permissions issue, but the Perl script still fails after indicating the
inability to find the CSV file in the temporary directory.
With a Strawberry Perl installation in place, and explicitly pointing
WriteXLS() to that Perl binary, I get a successful creation of the Excel file:
> WriteXLS(iris, "test.xlsx", perl = "C:\\Strawberry\\perl\\bin\\perl")
>
> WriteXLS(iris, "test.xlsx", perl = "C:/Strawberry/perl/bin/perl")
>
Thus, I am confused as to the source of the incompatibility, and may be missing
some nuances regarding the Perl binary and related components in RTools.
Any thoughts/pointers would be appreciated.
Thank you,
Marc Schwartz
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package
Dear Marc Schwartz,
В Fri, 19 Jul 2024 10:49:31 -0400
Marc Schwartz пишет:
> . No such file or
> directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
This looks like an extra carriage return has messed up the output.
By debugging WriteXLS and running the command line manually with perl
-d, I can confirm this:
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:135):
135:my @FileNames = "";
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:136):
136:open (DFHANDLE, $Encode, "$CSVPath/FileNames.txt") || die
"ERROR: cannot open $CSVPath/FileNames.txt. $!\n";
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:137):
137:@FileNames = ;
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:138):
138:close DFHANDLE;
DB<3> x \@FileNames
0 ARRAY(0xa005e3c08)
0 "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM\cJ"
DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:141):
141:chomp(@FileNames);
DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:302):
302:foreach my $FileName (@FileNames) {
DB<4> x \@FileNames
0 ARRAY(0xa005e3c08)
0 "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM"
Since the R code always uses a text-mode connection with WriteLines,
it always results in CR-LF line endings on Windows. The difference must
be in the default PerlIO layers applied by Strawberry Perl by default.
MSYS is based on Cygwin, which does its best to pretend to be an
Unix-like environment, so it's reasonable for an MSYS build of Perl to
default to LF line endings. But that means special-casing the MSYS
build of Perl:
DB<5> x $Encode
0 '<:encoding(utf8)'
DB<6> x $^O
0 'msys'
...and adding $Encode .= ":crlf" if $^O eq 'msys'; somewhere.
--
Best regards,
Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package
Hi Ivan,
Thanks kindly for your expedient reply and pointer to the LF/CRLF issue. Not
sure that I would have found that issue so quickly, so was hoping for some
intuition here, as you have provided.
Thanks!
Regards,
Marc
-Original Message-
From: Ivan Krylov mailto:ikry...@disroot.org>>
Date: Friday, July 19, 2024 at 11:18 AM
To: Marc Schwartz mailto:marc_schwa...@me.com>>
Cc: mailto:r-package-devel@r-project.org>>
Subject: Re: [R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN
Package
Dear Marc Schwartz,
В Fri, 19 Jul 2024 10:49:31 -0400
Marc Schwartz mailto:marc_schwa...@me.com>> пишет:
> . No such file or
> directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
This looks like an extra carriage return has messed up the output.
By debugging WriteXLS and running the command line manually with perl
-d, I can confirm this:
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:135):
135: my @FileNames = "";
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:136):
136: open (DFHANDLE, $Encode, "$CSVPath/FileNames.txt") || die
"ERROR: cannot open $CSVPath/FileNames.txt. $!\n";
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:137):
137: @FileNames = ;
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:138):
138: close DFHANDLE;
DB<3> x \@FileNames
0 ARRAY(0xa005e3c08)
0 "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM\cJ"
DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:141):
141: chomp(@FileNames);
DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:302):
302: foreach my $FileName (@FileNames) {
DB<4> x \@FileNames
0 ARRAY(0xa005e3c08)
0 "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM"
Since the R code always uses a text-mode connection with WriteLines,
it always results in CR-LF line endings on Windows. The difference must
be in the default PerlIO layers applied by Strawberry Perl by default.
MSYS is based on Cygwin, which does its best to pretend to be an
Unix-like environment, so it's reasonable for an MSYS build of Perl to
default to LF line endings. But that means special-casing the MSYS
build of Perl:
DB<5> x $Encode
0 '<:encoding(utf8)'
DB<6> x $^O
0 'msys'
...and adding $Encode .= ":crlf" if $^O eq 'msys'; somewhere.
--
Best regards,
Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to get arbitrary precise inputs from R for an Rcpp package?
> Khue Tran > on Fri, 19 Jul 2024 09:32:14 +1000 writes: > Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed > looked into Rmpfr and while the package can interface GNU MPFR with R > smoothly, as of right now, it doesn't have all the functions I need (ie. > eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the > precision is still limited by R's default double precision. Well, it depends *how* you input 0.1: the double precision representation of 0.1 is *NOT* the same as mathematically 1/10 and it cannot be. What you really want is either mpfr(0.1, 100) # 100 as an example ... to get a more precise # version of the '0.1' (double prec). ## *or*, e.g., 1 / mpfr(10, 100) # which is a more accurate approximation to # the mathematical fraction 1/10 ## if you really want that, I'd also recommend truly exact fractions require(gmp) as.bigq(1, 10) # or equivalently 1 / as.bigz(10) # which automatically makes an exact fraction > Thank you for the note, Dirk. I will keep in mind to send any future > questions regarding Rcpp to the Rcpp-devel mailing list. I understand that > the type used in the Boost library for precision is not one of the types > supported by SEXP, so it will be more complicated to map between the cpp > codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations > (and embarking on interfacing Eigen with Rmpfr is not a small task), does > taking input as strings seem like the best option for me to get precise > inputs? almost surely (that's also what you can do in Rmpfr).. Martin > Sincerely, > Khue > On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel wrote: >> >> Hi Khue, >> >> On 19 July 2024 at 06:29, Khue Tran wrote: >> | I am currently trying to get precise inputs by taking strings instead of >> | numbers then writing a function to decompose the string into a rational >> | with the denominator in the form of 10^(-n) where n is the number of >> | decimal places. I am not sure if this is the only way or if there is a >> | better method out there that I do not know of, so if you can think of a >> | general way to get precise inputs from users, it will be greatly >> | appreciated! >> >> That is one possible way. The constraint really is that the .Call() >> interface >> we use for all [1] extensions to R only knowns SEXP types which map to a >> small set of known types: double, int, string, bool, ... The type used by >> the Boost library you are using is not among them, so you have to add code >> to >> map back and forth. Rcpp makes that easier; it is still far from automatic. >> >> R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe that >> is >> good enough? Also note that Rcpp has a dedicated (low volume and friendly) >> mailing list where questions such as this one may be better suited. >> >> Cheers, Dirk >> >> [1] A slight generalisation. There are others but they are less common / >> not >> recommended. >> >> -- >> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> > [[alternative HTML version deleted]] > __ > 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] How to get arbitrary precise inputs from R for an Rcpp package?
On 2024-07-19 12:37 p.m., Martin Maechler wrote:
Khue Tran
on Fri, 19 Jul 2024 09:32:14 +1000 writes:
> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed
> looked into Rmpfr and while the package can interface GNU MPFR with R
> smoothly, as of right now, it doesn't have all the functions I need (ie.
> eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), the
> precision is still limited by R's default double precision.
Well, it depends *how* you input 0.1:
the double precision representation of 0.1 is *NOT* the same as
mathematically 1/10 and it cannot be.
What you really want is either
mpfr(0.1, 100) # 100 as an example ... to get a more precise
# version of the '0.1' (double prec).
## *or*, e.g.,
1 / mpfr(10, 100) # which is a more accurate approximation to
# the mathematical fraction 1/10
It seems like mpfr("0.1", 100) works pretty well. I'd assume it does
the parsing, rather than parse 0.1 to the closest double, and convert that.
Duncan Murdoch
## if you really want that, I'd also recommend truly exact fractions
require(gmp)
as.bigq(1, 10) # or equivalently
1 / as.bigz(10) # which automatically makes an exact fraction
> Thank you for the note, Dirk. I will keep in mind to send any future
> questions regarding Rcpp to the Rcpp-devel mailing list. I understand
that
> the type used in the Boost library for precision is not one of the types
> supported by SEXP, so it will be more complicated to map between the cpp
> codes and R. Given Rmpfr doesn't provide all necessary mpfr calculations
> (and embarking on interfacing Eigen with Rmpfr is not a small task), does
> taking input as strings seem like the best option for me to get precise
> inputs?
almost surely (that's also what you can do in Rmpfr)..
Martin
> Sincerely,
> Khue
> On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel
wrote:
>>
>> Hi Khue,
>>
>> On 19 July 2024 at 06:29, Khue Tran wrote:
>> | I am currently trying to get precise inputs by taking strings instead
of
>> | numbers then writing a function to decompose the string into a
rational
>> | with the denominator in the form of 10^(-n) where n is the number of
>> | decimal places. I am not sure if this is the only way or if there is a
>> | better method out there that I do not know of, so if you can think of
a
>> | general way to get precise inputs from users, it will be greatly
>> | appreciated!
>>
>> That is one possible way. The constraint really is that the .Call()
>> interface
>> we use for all [1] extensions to R only knowns SEXP types which map to a
>> small set of known types: double, int, string, bool, ... The type used
by
>> the Boost library you are using is not among them, so you have to add
code
>> to
>> map back and forth. Rcpp makes that easier; it is still far from
automatic.
>>
>> R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe
that
>> is
>> good enough? Also note that Rcpp has a dedicated (low volume and
friendly)
>> mailing list where questions such as this one may be better suited.
>>
>> Cheers, Dirk
>>
>> [1] A slight generalisation. There are others but they are less common /
>> not
>> recommended.
>>
>> --
>> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>>
> [[alternative HTML version deleted]]
> __
> 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] How to get arbitrary precise inputs from R for an Rcpp package?
Just for your info:
> exp(mpfr("0.1", 152))
1 'mpfr' number of precision 152 bits
[1] 1.1051709180756476248117078264902466682245471948
So it looks like your approach of parsing the numbers yourself makes sense.
You can find the R parser here:
https://github.com/wch/r-source/blob/b64422334a8269535718efd9a1f969c94b103056/src/main/gram.y#L2577-L2705
I don't know how much of that you want to replicate, but I suppose
handling the weird cases (e.g. 0x1p1) the way R does will make it easier
for your users.
Duncan Murdoch
On 2024-07-18 4:29 p.m., Khue Tran wrote:
Hi,
I am trying to create an Rcpp package that involves arbitrary precise
calculations. The function to calculate e^x below with 100 digits precision
works well with integers, but for decimals, since the input is a double,
the result differs a lot from the arbitrary precise result I got on
Wolfram.
I understand the results are different since 0.1 cannot be represented
precisely in binary with limited bits. It is possible to enter 1 then 10
and get the multiprecision division of these two integers to attain a more
precise 0.1 in C++, but this method won't work on a large scale. Thus, I am
looking for a general solution to get more precise inputs?
The dummy example is as follows:
library(Rcpp)
sourceCpp(code = '
#include
#include
// [[Rcpp::depends(BH)]]
// [[Rcpp::export]]
std::string calculateExp100(double x) {
boost::multiprecision::cpp_dec_float_100 bx = x;
boost::multiprecision::cpp_dec_float_100 expx = exp(bx);
return expx.str(50);
}
')
[1] represents the R output and [W] for Wolfram results
calculateExp100(1) # Agrees with Wolfram answer all the way to the last
digit
[1] "2.7182818284590452353602874713526624977572470937"
[W] 2.7182818284590452353602874713526624977572470936999595749669676277...
calculateExp100(0.1) # Differs pretty significantly from Wolfram's answer
[1] "1.1051709180756476309466388234587796577416634163742"
[W] 1.1051709180756476248117078264902466682245471947375187187928632894...
I am currently trying to get precise inputs by taking strings instead of
numbers then writing a function to decompose the string into a rational
with the denominator in the form of 10^(-n) where n is the number of
decimal places. I am not sure if this is the only way or if there is a
better method out there that I do not know of, so if you can think of a
general way to get precise inputs from users, it will be greatly
appreciated!
Thank you!
Best,
Khue Tran
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is winbuilder "offline"?
On Fri, 19 Jul 2024 10:18:27 +0200 Uwe Ligges wrote: > Not that I know, which queue do you mean? Apologies for my ignorance but I don't understand the question. I did not choose a "queue". I simply (as I have always done in the past) pointed my browser at https://win-builder.r-project.org/ . I then clicked on "upload page" which took me to https://win-builder.r-project.org/upload.aspx . I then clicked on "Browse" under "R-release", chose the file to upload (kanova_0.1-4.tar.gz) and clicked on "Upload File". There were no indications of any problems. I waited for an email from winbuilder, but this never came. What am I missing? cheers, Rolf P.S. Is "R-release" the queue in question? R. -- Honorary Research Fellow Department of Statistics University of Auckland Stats. Dep't. (secretaries) phone: +64-9-373-7599 ext. 89622 Home phone: +64-9-480-4619 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is winbuilder "offline"?
On 20.07.2024 01:52, Rolf Turner wrote: On Fri, 19 Jul 2024 10:18:27 +0200 Uwe Ligges wrote: Not that I know, which queue do you mean? Apologies for my ignorance but I don't understand the question. I did not choose a "queue". I simply (as I have always done in the past) pointed my browser at https://win-builder.r-project.org/ . I then clicked on "upload page" which took me to https://win-builder.r-project.org/upload.aspx . I then clicked on "Browse" under "R-release", chose the file to upload (kanova_0.1-4.tar.gz) and clicked on "Upload File". There were no indications of any problems. I waited for an email from winbuilder, but this never came. Strange. Your package has been processed. Have you tried again? Are you sure the maintainer address is specified correctly and that the auto generated message did not make it onto your spam box? If it still does not work, please send me the tarball and I'll take a look. Best, Uwe What am I missing? cheers, Rolf P.S. Is "R-release" the queue in question? R. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
