Re: [R-pkg-devel] [Re] warning: type of ‘zhpevx_’ does not match original declaration [-Wlto-type-mismatch]

[Tomas Kalibera]

On 12/19/20 12:57 AM, Pierre Lafaye de Micheaux wrote:
> Thank you Tomas,
>
> For those interested, here is (attached file) how I modified the Cpp 
> file following the (last?) advice I received from Tomas. I plan to 
> investigate the iso_c_binding approach suggested by Ivan in a future 
> version of the package, but I just wanted to give it a try with this 
> approach given all the time I spent trying to make it work. Maybe this 
> will be useful to others as well who plan to use complex numbers.


Dear Pierre,


I meant rather something like this (in plain C, there is no need to use 
C++ for this):


---


#include ��� /* for size_t (FC_LEN_T) */

#include �� /* for FC_LEN_T, FCONE */
#include ��� /* for FCONE */
#include � /* for F77_... */
#include  /* for Rcomplex */

void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
 � const int *n, Rcomplex *ap, const double *vl,
 � const double *vu, const int *il, const int *iu,
 � const double *abstol, int *m, double *w,
 � Rcomplex *z, const int *ldz, Rcomplex *work, 
double *rwork,
 � int *iwork, int *ifail, int *info,
#ifdef FC_LEN_T
 � FC_LEN_T jobz_len, FC_LEN_T range_len, FC_LEN_T 
uplo_len
#endif
 � );

void zhpevxC(char **jobz, char **range, char **uplo, int *n, Rcomplex *ap,
  double *vl, double *vu, int *il, int *iu, double *abstol, 
int *m,
  double *w, Rcomplex *z, int *ldz, Rcomplex *work, double 
*rwork,
  int *iwork, int *ifail, int *info) {

 ��� F77_CALL(zhpevx)(*jobz, *range, *uplo, n, ap, vl, vu, il, iu, 
abstol, m, w,
  z, ldz, work, rwork, iwork, ifail, info FCONE 
FCONE FCONE);
}

-


with gfortran 8.3, you still get the warnings due to size_t vs "long 
int", and due to the complex type (the compiler complains between the 
difference between _Complex and Rcomplex). With newer gfortran (9.3) 
there are no warnings.


>
> On a side note, my intention was not to do "runtime tricks (such as 
> copying the memory, etc) to silence benign compiler warnings" but only 
> to remove all warnings that prevent the CRAN from accepting my package 
> (I'm sure they have good reasons to do so). I believe these warnings 
> should not appear with gcc/gfortran 8.3.0 which is the standard 
> version on Debian Buster (the current stable version of Debian which I 
> am sure is installed on many production servers).

When you are copying the memory from Rcomplex array to _Complex array, 
you are still assuming the memory layout is compatible. But in addition, 
you have more code, use more memory, spend execution time copying 
(that's what I meant by runtime tricks). In case the memory layouts were 
actually different, there would still be a problem and it would be 
harder to find, because you have silenced the warning. I think it is 
strictly better to use a version that is not hiding this potential 
problem, along the lines I've written above. Also there should be no 
need to copy the incoming characters as in the original version. And, 
one can just write "n" instead of "&n[0]".


A portable version that would work for older and newer compilers (and 
other compilers) could only be created using iso_c_binding.


If you just wanted to silence the warnings (but, really, I think that 
would not be a good thing to do), you in principle still do that by 
redefining FC_LEN_T and Rcomplex, without any runtime overhead, but that 
would be hiding potential problems as well.


Best
Tomas

>
> Thank you again all for sharing your precious time.
>
> Kind regards,
> Pierre L.
> 
> *From:* Tomas Kalibera 
> *Sent:* Friday, 18 December 2020 19:14
> *To:* Pierre Lafaye de Micheaux ; Ivan Krylov 
> 
> *Cc:* R Package Devel 
> *Subject:* Re: [R-pkg-devel] [Re] warning: type of �zhpevx_� does not 
> match original declaration [-Wlto-type-mismatch]
> On 12/18/20 8:25 AM, Pierre Lafaye de Micheaux wrote:
>> Dear Ivan,
>>
>> Thank you for your comment. And also for the previous one.
>>
>> I indeed made a mistake with JOBZ, RANGE and UPLO, now changed to:
>>
>> � � const char *CJOBZ = jobz[0];
>> � � const char *CRANGE = range[0];
>> � � const char *CUPLO = uplo[0];
>> ...
>> � � delete[] CJOBZ;
>> � � delete[] CRANGE;
>> � � delete[] CUPLO;
>
> Dear Pierre,
>
>
> this unfortunately still does not look right. You are calling 
> "delete[]" on something you have not allocated with "new". This code 
> will not work (or if so, only by coincidence only sometimes, but crash 
> other times or produce incorrect results) and you should be seeing a 
> number of compiler warnings if not errors. "jobz" is a "char *" 
> (unless something changed from you previous example), so jobz[0] is a 
> "char", so not a pointer at all.
>
>
>>
>> I did a bit of F77 programming almost 20 years ago when

Re: [R-pkg-devel] Package Encoding and Literal Strings

[jo...@jorisgoosen.nl]

Hello Tomas,

Thank you for the feedback and your summary of how things now work and what
goes wrong for the tao- and mathot-string confirms all of my suspicions.
And it also describes my exact problem fairly well.

It seems it does come down to R not keeping the UTF-8 encoding of the
literal strings on Windows with a "typical codepage" when loading a
package.
This despite reading it from file in that particular encoding and also
specifying the same in DESCRIPTION.
While `eval(parse(..., encoding="UTF-8"))` *does* keep the encoding on the
literal strings. Which means there is some discrepancy between the two.
That means the way a package is loaded it uses a different path then when
using `eval(parse(..., encoding="UTF-8"))`?

You mention:
> Strings that cannot be represented in the native encoding like tao will
get the escapes, and so cannot be converted back to UTF-8. This is not
great, but I  see it was the case already in 3.6 (so not a recent
regression) and I don't think it would be worth the time trying to fix that
- as discussed earlier, only switching to UTF-8 would fix all of these
translations, not just one.

Not a recent regression means it used to work the same for both and keeping
the UTF-8 encoding?
I've tried R 3 and it already doesnt work there, I also tried 2.8 but
couldnt get my testpkg (simplified to use "charToRaw" instead of a C-call)
to install there.
However, having this work would already be quite useful as our custom GUI
on top of R is fully UTF-8 anyhow.

And I would certainly be up for figuring out how to fix the regression so
that we can use this until your work on the UTF-8 version with UCRT is
released.
On the other hand, maybe this would not be the wisest investment of my
time.

I've tried using the installer and toolchain you linked to in
https://developer.r-project.org/Blog/public/2020/07/30/windows/utf-8-build-of-r-and-cran-packages/index.html
and use that to compile our software.
This normally works with the Rtools toolchain, but it seems that "make" is
missing from your toolchain. When I build (our project with Riniside in it)
using your toolchain in the beginning of PATH and using mingw32-make from
rtools40 I run into problems of a missing "cc1plus".

If I read https://mxe.cc/ it seems it is meant for cross-compiling, not
locally on Windows?
Maybe that is what is going wrong.
But despite trying for quite a bit I couldn't get our software to compile
in such a way it could link with R.
Which means I couldn't test if it solves our problem...

Cheers,
Joris


On Fri, 18 Dec 2020 at 18:05, Tomas Kalibera 
wrote:

> Hi Joris,
>
> thanks for the example. You can actually simply have Test.R assign the two
> variables and then run
>
> Encoding(utf8StringsPkg1::mathotString)
> charToRaw(utf8StringsPkg1::mathotString)
> Encoding(utf8StringsPkg1::tao)
> charToRaw(utf8StringsPkg1::tao)
>
> I tried on Linux, Windows/UTF-8 (the experimental version) and
> Windows/latin-1 (released version). In all cases, both strings are
> converted to native encoding. The mathotString is converted to latin-1
> fine, because it is representable there. The tao string when running in
> latin-1 locale gets the escapes :
>
> "<99><86>"
>
> Btw, the parse(,encoding="UTF-8") hack works, when you parse the modified
> Test.R file (with the two assignments), and eval the output, you will get
> those strings in UTF-8. But when you don't eval and print the parse tree in
> Rgui, it will not be printed correctly (again a limitation of these hacks,
> they could only do so much).
>
> When accessing strings from C, you should always be prepared for any
> encoding in a CHARSXP, so when you want UTF-8, use "translateCharUTF8()"
> instead of "CHAR()". That will work fine on representable strings like
> mathotString, and that is conceptually the correct way to access them.
>
> Strings that cannot be represented in the native encoding like tao will
> get the escapes, and so cannot be converted back to UTF-8. This is not
> great, but I  see it was the case already in 3.6 (so not a recent
> regression) and I don't think it would be worth the time trying to fix that
> - as discussed earlier, only switching to UTF-8 would fix all of these
> translations, not just one. Btw, the example works fine on the
> experimentation UTF-8 build on Windows.
>
> I am sorry there is not a simple fix for non-representable characters.
>
> Best
> Tomas
>
>
>
> On 12/18/20 1:53 PM, jo...@jorisgoosen.nl wrote:
>
> Hello Tomas,
>
> I have made a minimal example that demonstrates my problem:
> https://github.com/JorisGoosen/utf8StringsPkg
>
> This package is encoded in UTF-8 as is Test.R. There is a little Rcpp
> function in there I wrote that displays the bytes straight from R's CHAR to
> be sure no conversion is happening.
> I would expect that the mathotString had "C3 B4" for "ô" but instead it
> gets "F4". As you can see when you run
> `utf8StringsPkg::testutf8_in_locale()`.
>
> Cheers,
> Joris
>
>
>
> On Fri, 18 Dec 2020 at 11:48, Tomas Kaliber

Re: [R-pkg-devel] Package Encoding and Literal Strings

[Tomas Kalibera]

Hi Joris,

On 12/21/20 7:33 PM, jo...@jorisgoosen.nl wrote:
> Hello Tomas,
>
> Thank you for the feedback and your summary of how things now work and 
> what goes wrong for the tao- and mathot-string confirms all of my 
> suspicions. And it also describes my exact problem fairly well.
>
> It seems it does come down to R not keeping the UTF-8 encoding of the 
> literal strings on Windows with a "typical codepage" when loading a 
> package.
> This despite reading it from file in that particular encoding and also 
> specifying the same in DESCRIPTION.
> While `eval(parse(..., encoding="UTF-8"))` *does* keep the encoding on 
> the literal strings. Which means there is some discrepancy between the 
> two.
> That means the way a package is loaded it uses a different path then 
> when using `eval(parse(..., encoding="UTF-8"))`?

Yes, it must be a different path. The DESCRIPTION field defines what 
encoding is the input in, so that R can read it. It does not tell R how 
it should represent the strings internally. The behavior is ok, well 
except for non-representable characters.

> You mention:
> > Strings that cannot be represented in the native encoding like tao 
> will get the escapes, and so cannot be converted back to UTF-8. This 
> is not great, but I  see it was the case already in 3.6 (so not a 
> recent regression) and I don't think it would be worth the time trying 
> to fix that - as discussed earlier, only switching to UTF-8 would fix 
> all of these translations, not just one.
>
> Not a recent regression means it used to work the same for both and 
> keeping the UTF-8 encoding?
> I've tried R 3 and it already doesnt work there, I also tried 2.8 but 
> couldnt get my testpkg (simplified to use "charToRaw" instead of a 
> C-call) to install there.
> However, having this work would already be quite useful as our custom 
> GUI on top of R is fully UTF-8 anyhow.
By "not a recent regression" I meant it wasn't broken recently. It 
probably never worked the way you (and me and probably everyone else) 
would like it to work, that is it probably always translated to native 
encoding, because that was the only option except rewriting all of our 
code, packages, external libraries to use UTF-16LE (as discussed before).
> And I would certainly be up for figuring out how to fix the regression 
> so that we can use this until your work on the UTF-8 version with UCRT 
> is released.
> On the other hand, maybe this would not be the wisest investment of my 
> time.

I bet your applications do more than just load a package and then access 
string literals in the code. And as soon as you do anything with those 
strings, R may translate them to native encoding (well unless we 
document this does not happen, typically some code around connections, 
file paths, etc). So, providing a shortcut for this case I am afraid 
wouldn't help you much. If the problem was just parsing, you could also 
use "\u" escapes as workaround in the literals. Remember, the 
parse(,encoding="UTF-8") only could work in single-byte encodings.

> I've tried using the installer and toolchain you linked to in 
> https://developer.r-project.org/Blog/public/2020/07/30/windows/utf-8-build-of-r-and-cran-packages/index.html
>  
> and use that to compile our software.
> This normally works with the Rtools toolchain, but it seems that 
> "make" is missing from your toolchain. When I build (our project with 
> Riniside in it) using your toolchain in the beginning of PATH and 
> using mingw32-make from rtools40 I run into problems of a missing 
> "cc1plus".

Sorry, building native code is still involved with that demo. You would 
have to set PATHs and well maybe alter the installation or build from 
source, as described in
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/winutf8.html

What might be actually easier, you could try a current development 
version, I will send you a link.

> If I read https://mxe.cc/ it seems it is meant for cross-compiling, 
> not locally on Windows?
> Maybe that is what is going wrong.
> But despite trying for quite a bit I couldn't get our software to 
> compile in such a way it could link with R.
> Which means I couldn't test if it solves our problem...

You can compile native code locally on Windows, the toolchain includes a 
native compiler and I build R packages natively as well. 
Cross-compilation is used to build the compiler toolchain and external 
libraries for packages.

Cheers
Tomas

>
> Cheers,
> Joris
>
>
> On Fri, 18 Dec 2020 at 18:05, Tomas Kalibera  > wrote:
>
> Hi Joris,
>
> thanks for the example. You can actually simply have Test.R assign
> the two variables and then run
>
> Encoding(utf8StringsPkg1::mathotString)
> charToRaw(utf8StringsPkg1::mathotString)
> Encoding(utf8StringsPkg1::tao)
> charToRaw(utf8StringsPkg1::tao)
>
> I tried on Linux, Windows/UTF-8 (the experimental version) and
> Windows/latin-1 (released version). In a

Re: [R-pkg-devel] 9e5d

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 25 Sep 2019, at 15:39, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Thanks all.  I asked because I don't want to unnecessarily overburden the CRAN 
maintainers.  In this case,  it wasn't a minor bug.

-Roy

On Sep 25, 2019, at 4:36 AM, Dirk Eddelbuettel  wrote:


On 24 September 2019 at 11:43, Roy Mendelssohn - NOAA Federal via 
R-package-devel wrote:
| A few days ago I  had to resubmit because an external URL I was using in my 
vignette changed and the nightly builds were issuing warnings.  This morning a 
user reported a bug.  I have the fix and a new version,  but the test machines, 
 and I suppose it will also be true of CRAN,  are unhappy about the interval 
since last submit.  Should I just submit the new version anyway with a note in 
cram-comments that this is a bug fix.

Yes: AFAICT these are recommendations to not overburden CRAN.

And I have hit two distinct types:

- more than six uploads in six months (which happened when an upstream
 package was hyperactive) which lead me to space uploads out a little more
 as "one a month should be plenty" indeed

- less than seven days since the last upload (which lead me to just wait two
 days on a very recent "better bug fix to a bug fix" upload I made, and
 then got me the very automated processing)

You can look in the R sources for what the cutoffs are (which is how I
confirmed it was 7) and act accordingly.  So yes, in sum, explain what you do
to CRAN -- and some human will generally do the Right Thing.

(And big thanks and kudos to CRAN for the increased automation documented in
the short update at the end of the most recent R Journal issue. Very
impressive, and very well done.)

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] 9e5d

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 24 Sep 2019, at 19:43, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Hi All:

A few days ago I  had to resubmit because an external URL I was using in my 
vignette changed and the nightly builds were issuing warnings.  This morning a 
user reported a bug.  I have the fix and a new version,  but the test machines, 
 and I suppose it will also be true of CRAN,  are unhappy about the interval 
since last submit.  Should I just submit the new version anyway with a note in 
cram-comments that this is a bug fix.

Thanks,

-Roy

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] 3097

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 5 Aug 2019, at 18:48, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Using tools:::.check_package_datasets() produces the error,  but doesn't give 
out any more information.  I don't know enough about some fo the write() 
function.  If I write to csv of some sort,  will this information be preserved?

Thanks,

-Roy


On Aug 5, 2019, at 8:57 AM, Roy Mendelssohn - NOAA Federal 
 wrote:

Thanks.  What is surprising me is I can't reproduce the error either directly 
on my Mac or on rhub::windows and I am waiting for the result of win-builder  
(I can't check most rhub::linux  because it fails to correctly build a number 
of required packages,  something I have reported but still persists - like 
rgdal,  rerddap, crul,  ncdf4).

-Roy
-
On Aug 5, 2019, at 8:50 AM, Duncan Murdoch  wrote:

On 05/08/2019 10:51 a.m., Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:
Hi All:
The recent nighty CRAN checks on one of my packages reports:
Check: data for non-ASCII characters
Result: NOTE
   Note: found 1 marked UTF-8 string
When  originally submitted this was not the case.  All my data files are .RData 
files,  and even more so most are binary data.  If they were text files I could 
readily scan for UTF,  is there a way once I read the data into R to do a 
similar scan from within R.  I just ran the most recent  (Github) version of 
devtools::check() and it doesn't report an error.  Or is there a way I can get 
more specific information from the CRAN nightly build or Rhub or the like?

That message comes when the tools:::.check_package_datasets function detects a 
string containing a UTF-8 encoding.  You can run it directly and you might get 
a more informative message.  If not, I suppose you could fix() it and add some 
extra debugging messages

It's argument is "pkgDir"; I think that is the directory holding the files 
after untarring the .tar.gz file.

Duncan Murdoch

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] 3097

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 5 Aug 2019, at 16:57, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Thanks.  What is surprising me is I can't reproduce the error either directly 
on my Mac or on rhub::windows and I am waiting for the result of win-builder  
(I can't check most rhub::linux  because it fails to correctly build a number 
of required packages,  something I have reported but still persists - like 
rgdal,  rerddap, crul,  ncdf4).

-Roy
-
On Aug 5, 2019, at 8:50 AM, Duncan Murdoch  wrote:

On 05/08/2019 10:51 a.m., Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:
Hi All:
The recent nighty CRAN checks on one of my packages reports:
Check: data for non-ASCII characters
Result: NOTE
Note: found 1 marked UTF-8 string
When  originally submitted this was not the case.  All my data files are .RData 
files,  and even more so most are binary data.  If they were text files I could 
readily scan for UTF,  is there a way once I read the data into R to do a 
similar scan from within R.  I just ran the most recent  (Github) version of 
devtools::check() and it doesn't report an error.  Or is there a way I can get 
more specific information from the CRAN nightly build or Rhub or the like?

That message comes when the tools:::.check_package_datasets function detects a 
string containing a UTF-8 encoding.  You can run it directly and you might get 
a more informative message.  If not, I suppose you could fix() it and add some 
extra debugging messages

It's argument is "pkgDir"; I think that is the directory holding the files 
after untarring the .tar.gz file.

Duncan Murdoch

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] 3097

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 5 Aug 2019, at 19:13, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Okay I found it.  I looked at the code for  tools:::.check_package_datasets(),  
took out the core part,  ran every string  I had in every dataset,  it came 
out.  A degree symbol.

Thanks for telling me about the function.  Still surprised that the test 
machines don't flag it.  Or is this a new test on CRAN?

-Roy


On Aug 5, 2019, at 10:48 AM, Roy Mendelssohn - NOAA Federal 
 wrote:

Using tools:::.check_package_datasets() produces the error,  but doesn't give 
out any more information.  I don't know enough about some fo the write() 
function.  If I write to csv of some sort,  will this information be preserved?

Thanks,

-Roy


On Aug 5, 2019, at 8:57 AM, Roy Mendelssohn - NOAA Federal 
 wrote:

Thanks.  What is surprising me is I can't reproduce the error either directly 
on my Mac or on rhub::windows and I am waiting for the result of win-builder  
(I can't check most rhub::linux  because it fails to correctly build a number 
of required packages,  something I have reported but still persists - like 
rgdal,  rerddap, crul,  ncdf4).

-Roy
-
On Aug 5, 2019, at 8:50 AM, Duncan Murdoch  wrote:

On 05/08/2019 10:51 a.m., Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:
Hi All:
The recent nighty CRAN checks on one of my packages reports:
Check: data for non-ASCII characters
Result: NOTE
  Note: found 1 marked UTF-8 string
When  originally submitted this was not the case.  All my data files are .RData 
files,  and even more so most are binary data.  If they were text files I could 
readily scan for UTF,  is there a way once I read the data into R to do a 
similar scan from within R.  I just ran the most recent  (Github) version of 
devtools::check() and it doesn't report an error.  Or is there a way I can get 
more specific information from the CRAN nightly build or Rhub or the like?

That message comes when the tools:::.check_package_datasets function detects a 
string containing a UTF-8 encoding.  You can run it directly and you might get 
a more informative message.  If not, I suppose you could fix() it and add some 
extra debugging messages

It's argument is "pkgDir"; I think that is the directory holding the files 
after untarring the .tar.gz file.

Duncan Murdoch

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] 5dff

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 5 Aug 2019, at 15:51, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Hi All:

The recent nighty CRAN checks on one of my packages reports:

Check: data for non-ASCII characters
Result: NOTE
Note: found 1 marked UTF-8 string

When  originally submitted this was not the case.  All my data files are .RData 
files,  and even more so most are binary data.  If they were text files I could 
readily scan for UTF,  is there a way once I read the data into R to do a 
similar scan from within R.  I just ran the most recent  (Github) version of 
devtools::check() and it doesn't report an error.  Or is there a way I can get 
more specific information from the CRAN nightly build or Rhub or the like?

Thanks,

-ROy

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] f319

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 25 Jul 2019, at 21:49, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Thanks,  actually have similar code for some other packages that must have been 
causing similar problems  (that part was from the original author,  I am now 
the maintainer).  Now I understand why he had something similar in the code.  
There is a comment about Namespaces not being handled properly in those 
packages.

Will try that.  I actually have rgdal and rgeos in Imports,  they were getting 
flagged in the CRAN nightly builds.  If I have them in that one statement,  
that should take care of both issues I believe.

But it would be nice to figure out why this is happening,  and only on Windows. 
 Sort of frustrating when you follow the guidelines but get failures,  but what 
also what is good about things like CRAN,  for whatever reason this will insure 
I work across platforms.

-Roy


On Jul 25, 2019, at 12:56 PM, Duncan Murdoch  wrote:

On 25/07/2019 3:47 p.m., Roy Mendelssohn - NOAA Federal wrote:
Okay I added rgeos but now it can't find rgdal.  as in:
Error: processing vignette 'using_plotdap.Rmd' failed with diagnostics:
package 'rgdal' is not available
--- failed re-building 'using_plotdap.Rmd'

A question I asked before is if there is anyway to check that 'rgdal' and 
'rgeos' are properly installed on the winbuider servers, as well as 'sf' and 
'sp'?  'devtools::check()' on my mac produces no errors,  same with  'rhub' 
using Fedora,  but I get the same errors on 'rhub' using Windows.So it 
appears to be a problem with Windows,  and again I am not calling these 
packages directly so I should not need to Import them.

You're right, you shouldn't need to import them if you don't call them 
directly.  However, if some package that you do need requires them, then your 
build or checks will fail without them.

It's probably getting tedious, but you could work around this as well, by 
figuring out what part of using_plotdap.Rmd needs rgdal, and wrapping that code 
in something like

if (requireNamespace("rgdal")) {
# code that needs it
}

I think this will mean you need to add rgdal to the Suggests list for your 
package to avoid other warnings.

Duncan Murdoch

Thanks,
-Roy
On Jul 25, 2019, at 12:38 PM, Duncan Murdoch  wrote:

On 25/07/2019 3:21 p.m., Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:
I have been testing a package for resubmission with bug fixes.  On the present 
CRAN builds I get:
Result: NOTE
   Namespaces in Imports field not imported from:
‘mapdata’ ‘maptools’ ‘plot3D’ ‘rgdal’ ‘rgeos’
All declared Imports should be used.
However,  if I remove rgeos from the imports I get from win builder:
Error in st_as_sfc.SpatialPolygons(sp::geometry(x), ...) :
package rgeos required for finding out which hole belongs to which exterior 
ring
Note that I am not calling 'rgeos',  either 'sf' or 'sp' is,  but does not 
appear to be properly importing all the need namespaces.
Best way  to proceed?  Include rgeos in Import and get the Note,  or 

A simple workaround would be to add a function that calls something from rgeos 
just to satisfy the check, e.g.

# Just to satisfy the checks...
dummy <- function() rgeos::getScale()

I don't think there are warnings if dummy is never used or exported, but if 
there are, I think that's a pretty harmless call to make.

Duncan Murdoch
**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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
http

Re: [R-pkg-devel] f319

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 25 Jul 2019, at 20:47, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Okay I added rgeos but now it can't find rgdal.  as in:

Error: processing vignette 'using_plotdap.Rmd' failed with diagnostics:
package 'rgdal' is not available
--- failed re-building 'using_plotdap.Rmd'


A question I asked before is if there is anyway to check that 'rgdal' and 
'rgeos' are properly installed on the winbuider servers, as well as 'sf' and 
'sp'?  'devtools::check()' on my mac produces no errors,  same with  'rhub' 
using Fedora,  but I get the same errors on 'rhub' using Windows.So it 
appears to be a problem with Windows,  and again I am not calling these 
packages directly so I should not need to Import them.

Thanks,

-Roy


On Jul 25, 2019, at 12:38 PM, Duncan Murdoch  wrote:

On 25/07/2019 3:21 p.m., Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:
I have been testing a package for resubmission with bug fixes.  On the present 
CRAN builds I get:
Result: NOTE
   Namespaces in Imports field not imported from:
‘mapdata’ ‘maptools’ ‘plot3D’ ‘rgdal’ ‘rgeos’
All declared Imports should be used.
However,  if I remove rgeos from the imports I get from win builder:
Error in st_as_sfc.SpatialPolygons(sp::geometry(x), ...) :
package rgeos required for finding out which hole belongs to which exterior 
ring
Note that I am not calling 'rgeos',  either 'sf' or 'sp' is,  but does not 
appear to be properly importing all the need namespaces.
Best way  to proceed?  Include rgeos in Import and get the Note,  or 

A simple workaround would be to add a function that calls something from rgeos 
just to satisfy the check, e.g.

# Just to satisfy the checks...
dummy <- function() rgeos::getScale()

I don't think there are warnings if dummy is never used or exported, but if 
there are, I think that's a pretty harmless call to make.

Duncan Murdoch

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] f319

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 25 Jul 2019, at 20:21, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

I have been testing a package for resubmission with bug fixes.  On the present 
CRAN builds I get:

Result: NOTE
   Namespaces in Imports field not imported from:
‘mapdata’ ‘maptools’ ‘plot3D’ ‘rgdal’ ‘rgeos’
All declared Imports should be used.

However,  if I remove rgeos from the imports I get from win builder:

Error in st_as_sfc.SpatialPolygons(sp::geometry(x), ...) :
package rgeos required for finding out which hole belongs to which exterior 
ring

Note that I am not calling 'rgeos',  either 'sf' or 'sp' is,  but does not 
appear to be properly importing all the need namespaces.

Best way  to proceed?  Include rgeos in Import and get the Note,  or 

Thanks,

-Roy


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] c18c

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 24 Jul 2019, at 02:44, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Thanks,  I was looking at the raw files,  not the .Rd files.  There are 
\keyword arguments in those file,  will have to search to see why they are 
getting generated.

-Roy


On Jul 23, 2019, at 6:02 PM, Duncan Murdoch  wrote:

On 23/07/2019 8:26 p.m., Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:
Hi All:
I am in the process of testing in order to submit a new version of a package to 
CRAN,  and I am getting clean results on everything but winbuilder_develop.  
There I am getting 1 Note:
Found the following \keyword or \concept entries with Rd markup:
 File 'checkBounds.Rd':
   \keyword{\code{checkBounds}}
 File 'getfileCoords.Rd':
   \keyword{\code{getFileCoords}}
 File 'make180.Rd':
   \keyword{\code{make180}}
 File 'make360.Rd':
   \keyword{\code{make360}}
Found the following \keyword or \concept entries
which likely give several index terms:
 File 'checkBounds.Rd':
   \keyword{latitude,}
   \keyword{longitude,}
 File 'make180.Rd':
   \keyword{(-180,180)}
   \keyword{(0,360)}
 File 'make360.Rd':
   \keyword{(-180,180)}
   \keyword{(0,360)}

I am not clear what this is calling for me to do, particularly since I doubt 
(-180, 180) or (0, 360) are keywords.
Guidance appreciated.

Can't you just look at those files (i.e. .../man/checkBounds.Rd, etc.) to see 
whether or not those declarations are contained in them?  If not, then there's 
clearly something weird happening at winbuilder_develop.

Duncan Murdoch

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] c18c

[Jendoubi Bedhiafi, Takoua]

I am out of office with occasional email access until the new year.

On 24 Jul 2019, at 01:26, Roy Mendelssohn - NOAA Federal via R-package-devel 
 wrote:

Hi All:

I am in the process of testing in order to submit a new version of a package to 
CRAN,  and I am getting clean results on everything but winbuilder_develop.  
There I am getting 1 Note:

Found the following \keyword or \concept entries with Rd markup:
 File 'checkBounds.Rd':
   \keyword{\code{checkBounds}}
 File 'getfileCoords.Rd':
   \keyword{\code{getFileCoords}}
 File 'make180.Rd':
   \keyword{\code{make180}}
 File 'make360.Rd':
   \keyword{\code{make360}}
Found the following \keyword or \concept entries
which likely give several index terms:
 File 'checkBounds.Rd':
   \keyword{latitude,}
   \keyword{longitude,}
 File 'make180.Rd':
   \keyword{(-180,180)}
   \keyword{(0,360)}
 File 'make360.Rd':
   \keyword{(-180,180)}
   \keyword{(0,360)}


I am not clear what this is calling for me to do, particularly since I doubt 
(-180, 180) or (0, 360) are keywords.

Guidance appreciated.

-Roy


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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