On 21.01.2023 03:47, Spencer Graves wrote:


On 1/20/23 7:32 PM, Duncan Murdoch wrote:
On 20/01/2023 8:16 p.m., Spencer Graves wrote:
Hello, All:


      My attempts to fix this problem exposed what seems to be a completely
unrelated problem:  All five GitHub Actions end now with:


Error: package or namespace load failed for ‘fda’ in namespaceExport(ns,
exports):
   undefined exports: refinery


      The package includes ~man/refinery.Rd, ~data/refinery.rda, and
NAMESPACE includes "export( ... refinery, ...)".


I think if you declare something as data by putting it in the data directory and using LazyData:true, you shouldn't also declare it as an export in the NAMESPACE file.


      I got the same negative results after deleting "LazyData: true" from DESCRIPTION.  (That's what I would expect, because there are 17 other *.rda files in the data subdirectory that are are mentioned in NAMESPACE and are not creating a problem.  In 2009 the package included both "data/refinery.rda" and "man/refinery.Rd".  They were erroneously removed at some point.  I'm now trying to restore them.)

So you have declared LazyData: true?
How does the other package access the data object? By imprt directives?
Perhaps you exported the data in the past via the NAMSPACE file? But then it has to be in sysdata.rda?



Sorry for the confusion with the BOM.
The encoding sting for UTF-16  with byte order mark is "UTF-16BE".
I'd believe much more should have gone wrong then. Perhaps it was some editor that really messed it up?

Best,
Uwe Ligges




       Thanks,
       Spencer


Duncan Murdoch



      ???
      I have Bitdefender installed on this computer.  A "Quick Scan"
produced nothing just now.


      Thanks,
      Spencer


On 1/20/23 5:08 PM, Duncan Murdoch wrote:
On 20/01/2023 6:02 p.m., Greg Hunt wrote:
xFEFF isn't a BOM in a UTF-8 file, its not anything.   The UTF-8 BOM is a
different sequence of bits.  If tools treat it as a BOM, that is
arguably a
problem.

You're right.  FEFF is the UTF-16 big endian BOM.  UTF-16 is a 16 bit
encoding, not at all the same as UTF-8.  I don't know how to read UTF-16
in R. Uwe's advice was for UTF-8.

Duncan Murdoch


On Sat, 21 Jan 2023 at 05:09, Bill Dunlap <williamwdun...@gmail.com>
wrote:

Setting the locale to "C" (or perhaps some other non-UTF-8 locale) will
show the BOM bytes.  E.g., on Windows I get:

Sys.getlocale()
[1] "LC_COLLATE=English_United States.utf8;LC_CTYPE=English_United
States.utf8;LC_MONETARY=English_United
States.utf8;LC_NUMERIC=C;LC_TIME=English_United States.utf8"
tools::showNonASCIIfile('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
rawToChar(readBin('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE',
what="raw", n=20))
[1] "export(AmpPhasDec"
Sys.setlocale(locale="C")
[1] "C"
tools::showNonASCIIfile('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
1: <ef><bb><bf>export(AmpPhasDecomp,
rawToChar(readBin('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE',
what="raw", n=20))
[1] "\357\273\277export(AmpPhasDec"

-Bill


On Fri, Jan 20, 2023 at 9:16 AM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

Hi, Ivan and Uwe:


            Thanks for your suggestions, but I've so far been unable
to get
them
to work.  see below.


On 1/20/23 9:22 AM, Uwe Ligges wrote:


On 20.01.2023 15:53, Ivan Krylov wrote:
В Fri, 20 Jan 2023 08:41:25 -0600
Spencer Graves <spencer.gra...@effectivedefense.org> пишет:

** byte-compile and prepare package for lazy loading
Error in parse(nsFile, keep.source = FALSE, srcfile = NULL) :
      1:1: unexpected input

tools::showNonASCIIfile('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
# 1: <ef><bb><bf>export(AmpPhaseDecomp,

Your NAMESPACE file starts with a U+FEFF ZERO WIDTH NO-BREAK SPACE.
You'll need to remove it, e.g. by re-creating the first line.


Note that this is also called "byte order mark" (BOM). Tell your
editor
not to create files with BOM.

You can also fix in R:

x <- readLines(..., encoding="UTF-8-BOM")
writeLines(x, ......)


            In RStudio 2022.12.0+353 (the current version),


tools::showNonASCIIfile('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')


returned "char(0)".  'readLines' and 'writeLines' as Uwe suggested
failed to fix it for me.


            The first problem I noticed with this was that RStudio could
not
read
the NAMESPACE file.  When I tried, it said, "File is binary rather than
text so cannot be opened by the source editor."  I changed something
using a different editor and did "git commit" and "git push", and got
the error on GitHub that I reported above.  I copied the file
elsewhere,
deleted it locally and from GitHub, then recreated it in LibreOffice by manually typing the first and last lines then copying the rest from a
copy I had saved elsewhere.  The RStudio would open the file, but I
still get the same error message as above from both "R CMD build fda"
locally and from GitHub Action at:


https://github.com/JamesRamsay5/fda


            Other suggestions?
            Thanks,
            Spencer Graves


Best,
Uwe Ligges






______________________________________________
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


     [[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

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

Reply via email to