Re: [R-pkg-devel] [External] Assistance Needed to Resolve CRAN Submission Note

[Richard M. Heiberger]

I seem to be later than some other respondents.  But for closure:


The patch you sent produces a msg <- ": 'tidy' is not HTML Tidy"
I would like to have the note tell the user how to update tidy, by giving an 
explicit
reference to https://www.html-tidy.org/



from the *shell* buffer in emacs

rmh@MacBook-Air-5 ~ % which tidy
/usr/bin/tidy
rmh@MacBook-Air-5 ~ % tidy --version
HTML Tidy for Mac OS X released on 31 October 2006 - Apple Inc. build 8018
rmh@MacBook-Air-5 ~ %



from the *R* buffer

> system("which tidy")
/usr/local/bin/tidy

> system("tidy --version")
HTML Tidy for Apple macOS version 5.8.0




> On May 19, 2024, at 01:30, Ivan Krylov  wrote:
>
> On Sat, 18 May 2024 21:10:18 +
> "Richard M. Heiberger"  wrote:
>
>> when checking a package and discovering these messages about html5,
>> can you generate an informational message about tidy with a link to
>> updating tidy?
>
> That's a useful suggestion.
>
> Would you mind testing the patch from
> <https://stat.ethz.ch/pipermail/r-devel/2023-August/082763.html>?
>
> If you or someone else here has a computer running macOS, what exactly
> does it print when running `tidy --version` (1) with an old version of
> Tidy (that comes with macOS) and (2) with a new (>= 5) version of Tidy?
>
> --
> Best regards,
> Ivan

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

Re: [R-pkg-devel] [External] Re: [External] Re: Assistance Needed to Resolve CRAN Submission Note

[Richard M. Heiberger]

exactly. when the --as-cran detects the need for that NOTE, it could prefix the 
initial instance of that NOTE with information about
updating the tidy installation on the package writer'smachine.

Sent from my iPhone

> On May 18, 2024, at 20:20, Duncan Murdoch  wrote:
>
> I don't think that will ever happen.  It only happens when a user tries an 
> "--as-cran" check, but doesn't have a current version of tidy installed.  
> CRAN does have the up-to-date versions installed, so they won't see this.
>
> Duncan Murdoch
>
>> On 2024-05-18 5:10 p.m., Richard M. Heiberger wrote:
>> this is a suggestion to CRAN.
>> when checking a package and discovering these messages about html5, can you 
>> generate an informational message about tidy with a link to updating tidy?
>> thank you
>> Rich
>> Sent from my iPhone
>>>> On May 17, 2024, at 15:32, Marc Girondot via R-package-devel 
>>>>  wrote:
>>>
>>> Here is the solution to update tidy to a recent version:
>>> https://www.html-tidy.org/
>>>
>>> Marc
>>>> Le 17/05/2024 à 17:59, Zeinab Mashreghi a écrit :
>>>> Hi,
>>>>
>>>> Thanks for all the suggestions and help.
>>>>
>>>> Yes, I'm using an Apple computer. The tidy version was from 2006. I 
>>>> submitted the package without any issues.
>>>>
>>>> Thanks again!
>>>>
>>>> Zeinab
>>>>
>>>> From: Ivan Krylov 
>>>> Date: Thursday, May 16, 2024 at 12:27 PM
>>>> To: Zeinab Mashreghi 
>>>> Cc: r-package-devel@r-project.org 
>>>> Subject: Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission 
>>>> Note
>>>> Notice: This is external email. Verify the sender and use caution with any 
>>>> content.
>>>>
>>>>
>>>> � Thu, 16 May 2024 16:01:45 +
>>>> Zeinab Mashreghi  �:
>>>>
>>>>> checking HTML version of manual ... NOTE
>>>>> Found the following HTML validation problems:
>>>>> All.data.html:4:1 (All.data.Rd:10): Warning:  inserting "type"
>>>>> attribute
>>>>> All.data.html:12:1 (All.data.Rd:10): Warning: 

Re: [R-pkg-devel] [External] Re: Assistance Needed to Resolve CRAN Submission Note

[Richard M. Heiberger]

this is a suggestion to CRAN.
when checking a package and discovering these messages about html5, can you 
generate an informational message about tidy with a link to updating tidy?

thank you
Rich

Sent from my iPhone

> On May 17, 2024, at 15:32, Marc Girondot via R-package-devel 
>  wrote:
>
> Here is the solution to update tidy to a recent version:
> https://www.html-tidy.org/
>
> Marc
>> Le 17/05/2024 à 17:59, Zeinab Mashreghi a écrit :
>> Hi,
>>
>> Thanks for all the suggestions and help.
>>
>> Yes, I'm using an Apple computer. The tidy version was from 2006. I 
>> submitted the package without any issues.
>>
>> Thanks again!
>>
>> Zeinab
>>
>> From: Ivan Krylov 
>> Date: Thursday, May 16, 2024 at 12:27 PM
>> To: Zeinab Mashreghi 
>> Cc: r-package-devel@r-project.org 
>> Subject: Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission Note
>> Notice: This is external email. Verify the sender and use caution with any 
>> content.
>>
>>
>> � Thu, 16 May 2024 16:01:45 +
>> Zeinab Mashreghi  �:
>>
>>> checking HTML version of manual ... NOTE
>>> Found the following HTML validation problems:
>>> All.data.html:4:1 (All.data.Rd:10): Warning:  inserting "type"
>>> attribute
>>> All.data.html:12:1 (All.data.Rd:10): Warning: 

Re: [R-pkg-devel] [External] Removing import(methods) stops exporting S4 "meta name"

[Richard M. Heiberger]

this looks like a relative of the issue I tripped on that is discussed in the 
email threads

https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010531.html

https://stat.ethz.ch/pipermail/r-devel/2024-March/083259.html

At issue is the default export of
exportPattern(".") 

System generated names, which is what ".__xxx__" looks like, seem to be the 
issue.
I can't make any specific recommendations behind connecting this current issue 
to my recent experience.

Rich


> On Mar 14, 2024, at 14:34, Michael Chirico  wrote:
> 
> importFrom(data.table,`.__T__[:base`)

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

Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Richard M. Heiberger]

Thank you, I will do that reversion in a few days.

Before I do, I want to ask if the default export generated by R CMD build 
should be changed.
the default is  exportPattern("."), which seems to be the cause of the problem.
Might the default be changed to exportPattern("^[^\\.]") ?

> On Mar 6, 2024, at 11:57, Joshua Ulrich  wrote:
>
> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger  wrote:
>>
>> Thank you Duncan, Jeff, Ivan.
>>
>> I did all that Duncan and Jeff suggested, plus a bit more that appeared to 
>> be necessary.
>> All of what I did is documented in the RcmdrPlugin.HH/NEWS file.
>>
>> Ivan's comments were received after I sent 1.1-50 to CRAN and it was 
>> accepted.
>>
> I recommend you revert all the changes you made that are documented in
> the package NEWS, and at minimum follow Ivan's advice to use
> exportPattern("^[^\\.]") instead of exportPattern("."). It would be
> even better to follow the advice in Writing R Extensions and list each
> exported object individually.
>
>> I suggest that my notes in the NEWS file, perhaps augmented with Ivan's 
>> comments,
>> might be added to utils/man/globalVariables.Rd and to the
>> "
>> section ‘Package
>> structure’ in the ‘Writing R Extensions’ manual.
>> "
>>
> That section of Writing R Extensions specifically says not to do what you did.
>
>Beware of patterns which include names starting with a period: some
>of these are internal-only variables and should never be exported,
>e.g. ‘.__S3MethodsTable__.’ (and loading excludes known cases).
>
> Duncan pointed out that '.__global__' is an internal-only variable
> created by globalVariables(), which means it should never be exported
> by a package. Imagine the number of conflicts there would be if every
> package that used globalVariables() exported the '.__global__'
> object... there would probably be thousands, yikes!
>
> It's possible that future versions of 'R CMD check' will error if
> there are any incorrectly exported internal variables (like
> '.__global__'), which would cause your package to fail.
>
> Best,
> Josh
>
>
>>
>>> On Mar 6, 2024, at 01:38, Ivan Krylov  wrote:
>>>
>>> В Tue, 5 Mar 2024 22:41:32 +
>>> "Richard M. Heiberger"  пишет:
>>>
>>>> Undocumented code objects:
>>>>  '.__global__'
>>>> All user-level objects in a package should have documentation
>>>> entries. See chapter 'Writing R documentation files' in the 'Writing R
>>>> Extensions' manual.
>>>
>>> This object is not here for the user of the package. If you don't
>>> export it, there will be no WARNING about it being undocumented. This
>>> variable is exported because of exportPattern(".") in the file
>>> NAMESPACE. The lone dot is a regular expression that matches any name
>>> of an R object.
>>>
>>> If you don't want to manually list your exports in the NAMESPACE file
>>> (which can get tedious) or generate it (which takes additional
>>> dependencies and build steps), you can use exportPattern('^[^\\.]') to
>>> export everything except objects with a name starting with a period:
>>> https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports
>>>
>>> --
>>> Best regards,
>>> Ivan
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
> --
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  http://www.fosstrading.com/


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

Re: [Rd] [External] Never exporting .__global__ and .__suppressForeign__?

[Richard M. Heiberger]

Ivan,

thank you for including me on this thread on R-devel.

Please be sure to see the last email in my R-pkg-devel thread on 
RcmdrPlugin.HH_1.1-48.tar.gz,
in which I discuss how I responded to this issue, specifically to my detailed 
discussion
in the RcmdrPlugion.HH/NEWS.

Rich


> On Mar 6, 2024, at 06:24, Ivan Krylov  wrote:
>
> Hello,
>
> (Dear Richard, I hope you don't mind being Cc:'d on this thread in
> R-devel. This is one of the ways we can prevent similar problems from
> happening in the future.)
>
> Sometimes, package authors who use both exportPattern('.') and
> utils::globalVariables(...) get confusing WARNINGs about undocumented
> exports:
> https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010531.html
>
> I would like to suggest adding the variables used by
> utils::globalVariables and utils::suppressForeignCheck to the list of
> things that should never be exported:
>
> Index: src/library/base/R/namespace.R
> ===
> --- src/library/base/R/namespace.R (revision 86054)
> +++ src/library/base/R/namespace.R (working copy)
> @@ -806,7 +806,8 @@
> if (length(exports)) {
> stoplist <- c(".__NAMESPACE__.", ".__S3MethodsTable__.",
>   ".packageName", ".First.lib", ".onLoad",
> -  ".onAttach", ".conflicts.OK", ".noGenerics")
> +  ".onAttach", ".conflicts.OK", ".noGenerics",
> +  ".__global__", ".__suppressForeign__")
> exports <- exports[! exports %in% stoplist]
> }
> if(lev > 2L) message("--- processing exports for ", dQuote(package))
>
> (Indeed, R CMD check is very careful to only access these variables
> using the interface functions in the utils package, so there doesn't
> seem to be any code that depends on them being exported, and they
> usually aren't.)
>
> Alternatively (or maybe additionally), it may be possible to enhance
> the R CMD check diagnostics by checking whether the name of the
> undocumented object starts with a dot and asking the user whether it
> was intended to be exported. This is not as easy to implement due to
> tools:::.check_packages working with the log output from
> tools::undoc(), not the object itself. Would a change to
> tools:::format.undoc be warranted?
>
> --
> Best regards,
> Ivan

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

Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Richard M. Heiberger]

Thank you Duncan, Jeff, Ivan.

I did all that Duncan and Jeff suggested, plus a bit more that appeared to be 
necessary.
All of what I did is documented in the RcmdrPlugin.HH/NEWS file.

Ivan's comments were received after I sent 1.1-50 to CRAN and it was accepted.

I suggest that my notes in the NEWS file, perhaps augmented with Ivan's 
comments,
might be added to utils/man/globalVariables.Rd and to the
"
section ‘Package
structure’ in the ‘Writing R Extensions’ manual.
"


> On Mar 6, 2024, at 01:38, Ivan Krylov  wrote:
>
> В Tue, 5 Mar 2024 22:41:32 +
> "Richard M. Heiberger"  пишет:
>
>> Undocumented code objects:
>>   '.__global__'
>> All user-level objects in a package should have documentation
>> entries. See chapter 'Writing R documentation files' in the 'Writing R
>> Extensions' manual.
>
> This object is not here for the user of the package. If you don't
> export it, there will be no WARNING about it being undocumented. This
> variable is exported because of exportPattern(".") in the file
> NAMESPACE. The lone dot is a regular expression that matches any name
> of an R object.
>
> If you don't want to manually list your exports in the NAMESPACE file
> (which can get tedious) or generate it (which takes additional
> dependencies and build steps), you can use exportPattern('^[^\\.]') to
> export everything except objects with a name starting with a period:
> https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports
>
> --
> Best regards,
> Ivan

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

Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Richard M. Heiberger]

Almost.

I used 
prompt(".__global__")
to create file
man/.__global__.Rd

This file does not appear in the tar.gz file, but without a note of rejection.
When I checked my disk directory directly
R CMD check RcmdrPlugin.HH
the file was rejected with

Found the following hidden files and directories:
  .DS_Store
  R/.DS_Store
  man/.__global__.Rd
These were most likely included in error. See section ‘Package
structure’ in the ‘Writing R Extensions’ manual.

I looked there
Section 1.1 says that the acceptable characters are
A-Za-z0-9._!#$%&+,;=@^(){}'[]
and "." and _ are explicitly included.

What should I try next?


> On Mar 5, 2024, at 18:21, Duncan Murdoch  wrote:
> 
> On 05/03/2024 5:41 p.m., Richard M. Heiberger wrote:
>> My package is being rejected by auto-check
>> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
>> Check: for missing documentation entries, Result: WARNING
>>  Undocumented code objects:
>>'.__global__'
>>  All user-level objects in a package should have documentation entries.
>>  See chapter 'Writing R documentation files' in the 'Writing R
>>  Extensions' manual.
>> The problem is that the string'.__global__'  is not in the package.
>> I can't find it and John Fox, the maintainer of Rcmdr, can'f find it.
>> Can someone help me understand why a non-existent string is being detected?
> 
> That's the variable modified by the `globalVariables()` function.  So it may 
> well exist in your package.  I'd guess the problem is that your package 
> exports functions by giving a pattern for the names instead of listing each 
> one separately, and it matches that variable.
> 
> Duncan Murdoch
> 
> 
> 

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

[R-pkg-devel] RcmdrPlugin.HH_1.1-48.tar.gz

[Richard M. Heiberger]

My package is being rejected by auto-check

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: for missing documentation entries, Result: WARNING
 Undocumented code objects:
   '.__global__'
 All user-level objects in a package should have documentation entries.
 See chapter 'Writing R documentation files' in the 'Writing R
 Extensions' manual.

The problem is that the string'.__global__'  is not in the package.
I can't find it and John Fox, the maintainer of Rcmdr, can'f find it.

Can someone help me understand why a non-existent string is being detected?

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

Re: [R-pkg-devel] [External] circular suggested packages

[Richard M. Heiberger]

Why are these functins in two different packages?
On the surface it looks like qrcode is a transformation function and opencv is 
its inverse.

> On Nov 7, 2023, at 14:55, Thierry Onkelinx  wrote:
>
> Dear all,
>
> The qrcode package converts text into a qrcode image. The opencv package is
> able to convert images with a qrcode into the text. opencv has a unit test
> that uses qrcode to generate a test image. Hence it lists qrcode as a
> suggested package.
>
> Would it be OK to implement the same unit test in qrcode? And thus
> requiring qrcode to list opencv as a suggested package. I know this is not
> allowed when depending or importing packages.
>
> Best regards,
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> http://www.inbo.be/
>
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
> ///
>
> 
>
> [[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-pkg-devel] is this expected behavior

[Richard M. Heiberger]

I have a demo file that uses a function defined in the package.
when I force the demo to be run with
R CMD check --test-dir=demo findme_1.0.tar.gz
then the function defined in the package is not recognized.

Here is the demo/findme.r file:

findme::findme()
findme()


Here is the result of:

R CMD check --test-dir=demo findme_1.0.tar.gz

* checking tests in ‘demo’ ...
  Running ‘findme.r’
 ERROR
Running the tests in ‘demo/findme.r’ failed.
Complete output:
  > findme::findme()
  [1] "You found me"
  > findme()
  Error in findme() : could not find function "findme"
  Execution halted


The first line with the "::" executed.
The second line, which assumed the function in the current package
would be exported, was not found.

Is this the expected behavior?

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

[R-pkg-devel] escaped latex specials

[Richard M. Heiberger]

There is a new NOTE.  This line with \& used to be acceptable.
I am not seeing what the suggested replacement is.

* checking Rd files ... [4s] NOTE
checkRd: (-1) bivariateNormal.Rd:42: Escaped LaTeX specials: \&

The full example is
\note{
  Based on the \code{galaxy} example on pages 204--205 in
  \emph{S \& S-PLUS Trellis Graphics User's Manual},
  Richard A. Becker and William S. Cleveland (1996),
\url{https://www.stat.auckland.ac.nz/~ihaka/courses/120/trellis.user.pdf} %% 
works 19Aug2019
}

Rich

[[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] [External] Formula modeling

[Richard M. Heiberger]

I am responding to a subset of what you asked.  There are packages which use 
multiple formulas
in their argument sequence.


What you have as a single formula with | as a separator
q | p | subject | time | rho ~ p + x + y | p + w + y | z + y 
I think would be better as a comma-separated list of formulas

q , p , subject , time , rho ~ p + x + y , p + w + y , z + y 

because in R notation | is usually an operator, not a separator.

lattice uses formulas and the | is used as a conditioning operator.

nlme and lme4 can have multiple formulas in the same calling sequence.

lme4 is newer.  from its ?lme4-package
‘lme4’ covers approximately the same ground as the earlier ‘nlme’
 package.

lme4 should probably be the modelyou are looking for for the package design.

> On Oct 07, 2021, at 17:20, pikappa.de...@gmail.com wrote:
> 
> Dear R-package-devel subscribers,
> 
> 
> 
> My question concerns a package design issue relating to the usage of
> formulas.
> 
> 
> 
> I am interested in describing via formulas systems of the form:
> 
> 
> 
> d = p + x + y 
> 
> s = p + w + y
> 
> p = z + y
> 
> q = min(d,s).
> 
> 
> 
> The context in which I am working is that of market models with, primarily,
> panel data. In the above system, one may think of the first equation as
> demand, the second as supply, and the third as an equation (co-)determining
> prices. The fourth equation is implicitly used by the estimation method, and
> it does not need to be specified when programming the R formula. If you need
> more information bout the system, you may check the package diseq.
> Currently, I am using constructors to build market model objects. In a
> constructor call, I pass [i] the right-hand sides of the first three
> equations as strings, [ii] an argument indicating whether the equations of
> the system have correlated shocks, [iii] the identifiers of the used dataset
> (one for the subjects of the panel and one for time), and [iv] the quantity
> (q) and price (p) variables. These four arguments contain all the necessary
> information for constructing a model.
> 
> 
> 
> I would now like to re-implement model construction using formulas, which
> would be a more regular practice for most R users. I am currently
> considering passing all the above information with a single formula of the
> form:
> 
> 
> 
> q | p | subject | time | rho ~ p + x + y | p + w + y | z + y 
> 
> 
> 
> where subject and time are the identifiers, and rho indicates whether
> correlated or independent shocks should be used.
> 
> 
> 
> I am unaware of other packages that use formulas in this way (for instance,
> passing the identifiers in the formula), and I wonder if this would go
> against any good practices. Would it be better to exclude some of the
> necessary elements for constructing the model? This might make the resuting
> formulas more similar to those of models with multiple responses or multiple
> parts. I am not sure, though, how one would use such model formulas without
> all the relevant information. Is there any suggested design alternative that
> I could check?
> 
> 
> 
> I would appreciate any suggestions and discussion!
> 
> 
> 
> Kind regards,
> 
> Pantelis
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=04%7C01%7Crmh%40temple.edu%7C21a51d63bc6242e5e24908d989d84fce%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637692385020500219%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=UKazmoIzXSn8DDQY3diUTPmVIg1cfTI3e1roXyo2DMQ%3Dreserved=0

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

Re: [R-pkg-devel] [External] R package submission fails due to using LaTeX functions that have not been implemented for building pdfs (not due to mathjaxr)

[Richard M. Heiberger]

> One more question. If I use mjeqn at the beginning of a paragraph it 
> automatically sets a line break afterwards.
> Any idea what I can do to prevent this?

follow it with
\vspace*{1ex}
to back up one line.

Rich

> On Jun 25, 2021, at 07:51, Marc Scherstjanoi  
> wrote:
> 
> Hi Wolfgang,
> 
> thank you for this information.
> I will try with \mjtdeqn and stick to the intended latex functions for 
> building the pdf.
> Moreover, we will bring up the more complicated equations in a vignette pdf.
> 
> One more question. If I use mjeqn at the beginning of a paragraph it 
> automatically sets a line break afterwards.
> Any idea what I can do to prevent this?
> 
> Best regards,
> Marc
> 
> - Ursprüngliche Mail -
> Von: "Viechtbauer, Wolfgang (SP)" 
> 
> An: "Marc Scherstjanoi" 
> CC: "Tiago Olivoto" , "Max Turgeon" 
> , r-package-devel@r-project.org
> Gesendet: Montag, 21. Juni 2021 10:29:17
> Betreff: RE: R package submission fails due to mathjaxr package
> 
> Hi Marc,
> 
> Thanks for the additional details. 
> 
> As far as I can tell, the problem has nothing to do with mathjaxr, but your 
> use of LaTeX commands that are not supported in creating the pdf manual 
> (which is not done by mathjaxr but R itself). See:
> 
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcran.r-project.org%2Fdoc%2Fmanuals%2Fr-release%2FR-exts.html%23Mathematicsdata=04%7C01%7Crmh%40temple.edu%7C95de1b8bbf3c4528e1ed08d937cfaaf7%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637602187342118099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kEmrK%2BB%2B9FfqGHu81LW%2BQ7iw0tFVLPCJ0Q2yVPCfvoQ%3Dreserved=0
> 
> You can use AMS extensions for the HTML docs since those are supported by 
> Mathjax, but not for the pdf manual.
> 
> So, for the pdf manual, you will have to write the equation without the use 
> of AMS extensions (and indeed use \mjtdeqn).
> 
> Best,
> Wolfgang
> 
>> -Original Message-
>> From: Marc Scherstjanoi [mailto:marc.scherstja...@thuenen.de]
>> Sent: Sunday, 20 June, 2021 23:16
>> To: Viechtbauer, Wolfgang (SP)
>> Cc: Tiago Olivoto; Max Turgeon; r-package-devel@r-project.org
>> Subject: Re: R package submission fails due to mathjaxr package
>> 
>> Hi Wolfgang, Tiago and Max
>> 
>> thank you for your reply. Let me first apologize. "due to mathjaxr" sounds a 
>> bit
>> harsh after the second reading.
>> I am very thankful for this nice package. It works really well for all of the
>> equations I have, and the HTML it creates is just nice.
>> The only problem is the PDF and I also found out that the align function 
>> (amsmath
>> latex package) is the actual error source. Furthermore, "\cr" is also giving 
>> an
>> error message.
>> 
>> For example, having
>> 
>> \mjdeqn{\begin{align} A_e(t) &= \left(A^T \cdot xi(t) \right)^T \cr &= A 
>> \cdot
>> diag(xi(t)) \end{align}}{Ae(t) = (A^T * xi(t))^T = A * diag(xi(t))}
>> 
>> in the \details section of the .Rd file leads to
>> 
>> "LaTeX errors:
>> ! LaTeX Error: Environment align undefined."
>> 
>> when building with "R CMD build /home/.../package"
>> 
>> but passes with "R CMD build /home/.../package --no-manual".
>> 
>> The aim of the align command is to set several equations in certain 
>> horizontal
>> positions (mostly oriented on the "="s, indicated by the "&"s) one below the
>> other.
>> I read about the possibility to use \mjtdeqn instead of \mjdeqn to specify 
>> LaTeX
>> commands for the PDF and HTML pages differently.
>> However, if the pdf necessarily needs to be created when submitting the 
>> package,
>> it would be better to have the equations aligned there as well.
>> For readability it would be a plus as I don't just have a couple of 
>> equations and
>> equation systems.
>> 
>> We are using the following setup:
>> Added "mathjaxr" to Imports and RdMacros fields of the DESCRIPTION file.
>> Added import(mathjaxr) to the NAMESPACE file.
>> Added "\loadmathjax" to the \description section.
>> 
>> I would be grateful for any idea how to convince the pdfTeX of the align 
>> command
>> or a similar solution.
>> 
>> Marc
>> 
>> - Ursprüngliche Mail -
>> Von: "Viechtbauer, Wolfgang (SP)" 
>> 
>> An: "Marc Scherstjanoi" , r-package-devel@r-
>> project.org
>> Gesendet: Sonntag, 20. Juni 2021 11:08:56
>> Betreff: RE: R package submission fails due to mathjaxr package
>> 
>> Hi Marc,
>> 
>> mathjaxr maintainer here. Can you provide a minimal reproducible example
>> illustrating the problem? If this is another case where the LaTeX command for
>> Mathjax does not work directly for creating the pdf (or vice-versa), then I 
>> would
>> like to document this (and a possible workaround) as was done here:
>> 
>> 

Re: [R-pkg-devel] An invalid URLs

[Richard M. Heiberger]

Is it perhaps an https:// address?  You browser will make the
adjustment.  CRAN will give this message.

On Thu, Mar 12, 2020 at 10:08 PM jared_wood  wrote:
>
> I write an URL of MalaCards (a database) in my description, because I need 
> the data in this database. However, there is an error here as followed:
>
>
>
>  Found the following (possibly) invalid URLs:
>
> URL: http://www.malacards.org/
>
>   From: DESCRIPTION
>
>   Status: 403
>
>   Message: Forbidden
>
>
>
> I don’t know why. The URL was picked up in the article of this database and I 
> can open it.
>
>
>
> This is the first time that I develop a package, therefore I am eager for 
> your help.
>
>
>
> Thanks.
>
>
>
> | |
> jared_wood
> |
> |
> jared_w...@163.com
> |
> 签名由网易邮箱大师定制
> [[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] no visible binding for '<<-' assignment note

[Richard M. Heiberger]

I would guess that your NAMESPACE file doesn't export dnormfun.

On Fri, Feb 21, 2020 at 1:38 PM Weimin Zhang  wrote:
>
> Thank you Max.
>
> The reason I used the super assignment  "<<-"  is because the "dnormfun" 
> function later called by function kronecker(X, Y, FUN = "*",...) through 
> FUN=" ". If I don't use the super assignment  "<<-"  then the kronecker 
> function cannot find "dnormfun" function. The question now seems that how I 
> can let the kronecker(X, Y, FUN = "*",...) know that "dnormfun" is a "FUN"?
>
> Thanks,
> Weimin
>
>
> 
> From: Max Turgeon 
> Sent: Thursday, February 20, 2020 10:50 AM
> To: Weimin Zhang ; r-package-devel@r-project.org 
> 
> Subject: Re: no visible binding for '<<-' assignment note
>
>
> Hi Weimin,
>
>
> From the R docs, if there is no visible binding for the deep assignment, 
> meaning there is the variable "dnormfun" not already defined in the parent 
> environment, then an assignment is made in the global assignment. Is this 
> really what you want to do, define a function "dnormfun" that is available in 
> the user's global environment? If yes, then you'll need to make a case for it 
> in your CRAN submision comments. If no, then you can probably just change 
> "<<-" to "<-".
>
>
> Best,
>
>
> Max Turgeon
> Assistant Professor
> Department of Statistics
> Department of Computer Science
> University of Manitoba
> maxturgeon.ca
>
>
> 
> From: R-package-devel  on behalf of 
> Weimin Zhang 
> Sent: February 19, 2020 11:48:38 AM
> To: r-package-devel@r-project.org
> Subject: [R-pkg-devel] no visible binding for '<<-' assignment note
>
> Dear all,
> In the last submission of my package the CRAN gave this note: "Check: R code 
> for possible problems, Result: NOTE: no visible binding for '<<-' 
> assignment..."
>
> How can I bypass this note?
>
> This is the local function which cause this note:
>   dnormfun <<- function(muvalue, sigmavalue, aNumber = gridY[i] ){
> force(aNumber)
> ansvalue=dnorm(aNumber,muvalue,sqrt(sigmavalue))
> return(ansvalue)
>   }
>
> The package can run normally at my machine. Any suggestion?
>
> Thanks,
>
> Weimin
>
>
>
>
> [[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

Re: [R-pkg-devel] Private S3 Method not Found

[Richard M. Heiberger]

latex() probably stopped midway through the compilation because you are
using intermediate routines other than the default.
For pdflatex, for example, you need to run
options(latexcmd='pdflatex', dviExtension='pdf', xdvicmd='open')
before using the latex() function.  See the Details section of ?latex.

To suppress the compilation, and stop with just the .tex file, use
print.default.
> tmp <- array(1:8, c(2,4), list(1:2,3:6))
> print.default(latex(tmp))
$file
[1] "tmp.tex"

$style
character(0)

attr(,"class")
[1] "latex"
>

The explicit result of the latex() function is a file name of class
"latex".  That way the automatic printing
feature of R shows the compiled file for that specific argument (tmp
in the example above).
Again in R terminology, the actual file "tmp.tex" is produced as a
side effect.  The tmp.tex file is designed
to be incorporated into your more comprehensive .tex file.

> tmp <- array(1:8, c(2,4), list(1:2,3:6))
> tmp.latex <- latex(tmp)
> print.default(tmp.latex)
$file
[1] "tmp.tex"

$style
character(0)

attr(,"class")
[1] "latex"


There are latex methods for many classes of objects.  formula is not
one of them.
>From your short initial description, it looks like what you are doing
could be thought of
as the latex.formula method.  I recommend doing it that way to get the
leverage of
all the other things the latex() and related functions do.  Once it is
working I suggest you
send your function to Frank Harrell (I cced him on this email) and
request that it be included as part of Hmisc::latex
You, of course, retain authorship

Rich

On Mon, Feb 17, 2020 at 10:54 AM  wrote:
>
> Hi Rich,
>
>
>
> I’m not doing the same thing as Hmisc::latex().  That generates a .tex file 
> and compiles it (or at least it appears to try to do that on my system, but 
> it stopped partway through for me).
>
>
>
> When I ran
>
>
>
> Hmisc::latex(a~b)
>
>
>
> It generated a .tex file for a table:
>
>
>
> \begin{table}[!tbp]
>
> \begin{center}
>
> \begin{tabular}{l}
>
> \hline\hline
>
> \multicolumn{1}{c}{}\tabularnewline
>
> \hline
>
> ~\tabularnewline
>
> a\tabularnewline
>
> b\tabularnewline
>
> \hline
>
> \end{tabular}\end{center}
>
> \end{table}
>
>
>
> While I’m wanting an equation:
>
>
>
> $$a = b$$
>
>
>
> Thanks,
>
>
>
> Bill
>
>
>
> From: Richard M. Heiberger 
> Sent: Monday, February 17, 2020 10:31 AM
> To: b...@denney.ws
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Private S3 Method not Found
>
>
>
> Please be consistent with the latex() function in the Hmisc package.  For 
> example, for an array x, latex (x) produces a complete latex table 
> environment.  See the ?latex helpfile for details.
>
>
>
> Rich
>
>
>
> On Mon, Feb 17, 2020 at 10:07  wrote:
>
> Hello,
>
>
>
> I'm working on a function in a package that will provide an exported
> function that will convert formula to LaTeX equations.  For that, it
> recursively goes through the formula converting objects of class "formula",
> "call", "name", and "(" to LaTeX.
>
>
>
> I have a private S3 generic function that I'm using for the conversion, but
> for some reason, the generic is not detected, and checking the package fails
> for that reason
> (https://travis-ci.org/billdenney/bsd.report/jobs/651510333):
>
>
>
> no applicable method for 'knit_print_helper_formula' applied to an object of
> class "name"
>
> Backtrace:
>
>   1. testthat::expect_equal(...)
>
>   4. bsd.report:::knit_print.formula(a ~ b(c))
>
>   6. bsd.report:::knit_print_helper_formula.formula(x, ..., replacements =
> replacements)
>
>   9. bsd.report:::knit_print_helper_formula.call(x[[3]], ...)
>
> 10. bsd.report:::knit_print_helper_formula.function_call(x, ...)
>
> 11. base::sapply(...)
>
> 12. base::lapply(X = X, FUN = FUN, ...)
>
> 13. bsd.report:::FUN(X[[i]], ...)
>
>
>
> But, there is a knit_print_helper_formula.name function call defined
> (https://github.com/billdenney/bsd.report/blob/master/R/knit_print.formula.R
> #L60-L79):
>
>
>
> knit_print_helper_formula <- function(x, ...) {
>
>   UseMethod("knit_print_helper_formula")
>
> }
>
>
>
> # Some other methods
>
>
>
> knit_print_helper_formula.name <- function(x, ...) {
>
> # Function body
>
> }
>
>
>
> Does anyone know why the S3 method for name class objects is not found when
> checking the package?
>
>
>
> Thanks,
>
>
>
> Bill
>
>
> [[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] Private S3 Method not Found

[Richard M. Heiberger]

Please be consistent with the latex() function in the Hmisc package.  For
example, for an array x, latex (x) produces a complete latex table
environment.  See the ?latex helpfile for details.

Rich

On Mon, Feb 17, 2020 at 10:07  wrote:

> Hello,
>
>
>
> I'm working on a function in a package that will provide an exported
> function that will convert formula to LaTeX equations.  For that, it
> recursively goes through the formula converting objects of class "formula",
> "call", "name", and "(" to LaTeX.
>
>
>
> I have a private S3 generic function that I'm using for the conversion, but
> for some reason, the generic is not detected, and checking the package
> fails
> for that reason
> (https://travis-ci.org/billdenney/bsd.report/jobs/651510333):
>
>
>
> no applicable method for 'knit_print_helper_formula' applied to an object
> of
> class "name"
>
> Backtrace:
>
>   1. testthat::expect_equal(...)
>
>   4. bsd.report:::knit_print.formula(a ~ b(c))
>
>   6. bsd.report:::knit_print_helper_formula.formula(x, ..., replacements =
> replacements)
>
>   9. bsd.report:::knit_print_helper_formula.call(x[[3]], ...)
>
> 10. bsd.report:::knit_print_helper_formula.function_call(x, ...)
>
> 11. base::sapply(...)
>
> 12. base::lapply(X = X, FUN = FUN, ...)
>
> 13. bsd.report:::FUN(X[[i]], ...)
>
>
>
> But, there is a knit_print_helper_formula.name function call defined
> (
> https://github.com/billdenney/bsd.report/blob/master/R/knit_print.formula.R
> #L60-L79
> 
> ):
>
>
>
> knit_print_helper_formula <- function(x, ...) {
>
>   UseMethod("knit_print_helper_formula")
>
> }
>
>
>
> # Some other methods
>
>
>
> knit_print_helper_formula.name <- function(x, ...) {
>
> # Function body
>
> }
>
>
>
> Does anyone know why the S3 method for name class objects is not found when
> checking the package?
>
>
>
> Thanks,
>
>
>
> Bill
>
>
> [[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] inconsistent behavior between R CMD check and interactive use

[Richard M. Heiberger]

So I am looking.  and it is even worse than what you suggest.
library()
shows that both HH and microplot are in both the system and personal libraries
Packages in library 'C:/Program Files/R/R-devel/library':
HH Version: 3.1-34
microplot Version: 1.0-15
Everything else in the system library belongs there.
Neither of these is the current CRAN version.

Packages in library 'C:/Users/rmh.DESKTOP-60G4CCO/R/win-library/4.0':
HH Version: 3.1-39 ## 3.1-37 is the current CRAN version
microplot Version: 1.0-42  ## this is the current CRAN version

I removed the ancient HH and microplot from c:/Program Files/R/R-devel/library
I left the correct current versions of both in
c:/Users/rmh.DESKTOP-60G4CCO/R/win-library/4.0

Then I ran the R CMD check again.
R CMD check --run-dontrun --as-cran HH_3.1-39.tar.gz

Very strange results:
"
* checking examples ... ERROR
Running examples in 'HH-Ex.R' failed
The error occurred in:


R Under development (unstable) (2019-12-05 r77528) -- "Unsuffered Consequences"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> pkgname <- "HH"
> source(file.path(R.home("share"), "R", "examples-header.R"))
> options(warn = 1)
> options(pager = "console")
> base::assign(".ExTimings", "HH-Ex.timings", pos = 'CheckExEnv')
> base::cat("name\tuser\tsystem\telapsed\n", file=base::get(".ExTimings", pos = 
> 'CheckExEnv'))
> base::assign(".format_ptime",
+ function(x) {
+   if(!is.na(x[4L])) x[1L] <- x[1L] + x[4L]
+   if(!is.na(x[5L])) x[2L] <- x[2L] + x[5L]
+   options(OutDec = '.')
+   format(x[1L:3L], digits = 7L)
+ },
+ pos = 'CheckExEnv')
>
> ### * 
> library('HH')
Error in library("HH") : there is no package called 'HH'
Execution halted
* checking PDF version of manual ... OK
* checking for non-standard things in the check directory ... OK
* checking for detritus in the temp directory ... OK
* DONE

Status: 1 ERROR
See
  'x:/HOME/rmh/HH-R.package/HH.Rcheck/00check.log'
for details.
"

it tested the new version until it got to examples.  Then it wanted to
run the examples
from the system library version.


Next try.
I will copy the current version (3.1-39, the one I am testing) of just
HH to the system library and run the check again.
That works!  It did a proper check of the correct version of the package.

R-devel seems to have a new check.  it is detecting files written not
in the temp directory.
I was doing so in several \dontrun{} examples, but I will fix them
before actually submitting to CRAN.

Thank you Duncan.

Rich


On Tue, Dec 10, 2019 at 2:27 PM Duncan Murdoch  wrote:
>
> (Rich, you've heard this already, this message is for others:)
>
> I think I've found the cause of this, and it might be a bug in the check
> code in R.
>
> Rich's package HH "Suggests" microplot, and microplot "Imports" HH.
> When running checks on the new version 3.1-38 of HH it appears the tests
> from the new version are run but the code being run is from the previous
> version 3.1-37 which is on CRAN.   I installed the old version
> indirectly when I installed microplot before running check.
>
> I've only seen this on Windows in R-devel when running --as-cran.  It
> doesn't happen in R-devel on MacOS with or without --as-cran, and I
> don't think it happens on Windows without --as-cran (but it might just
> be that there are no symptoms of testing the wrong version in that case).
>
> A workaround is to explicitly remove HH, then install the new version
> before running the check code.
>
> Duncan Murdoch
>
>
>
>
>
> On 08/12/2019 10:33 p.m., Richard M. Heiberger wrote:
> > Duncan,
> >
> > Thank you offering to look.
> > I have tried all the obvious things that I could think of.  None helped.
> > Perhaps you will think of something I haven't tried
> >
> > The reproducible example (not minimal) I can suggest is to use the
> > submitted file.
> >
> > ftp://CRAN.R-project.org/incoming/archive/HH_3.1-38.tar.gz
> >
> > On my windows machine
> >
> > R CMD check --as-cran HH_3.1-38.tar.gz
> > halts with
> >> BB <- likert(tmp[2:6,], box.width=unit(.4,"cm"), positiv

Re: [R-pkg-devel] inconsistent behavior between R CMD check and interactive use

[Richard M. Heiberger]

Duncan,

Thank you offering to look.
I have tried all the obvious things that I could think of.  None helped.
Perhaps you will think of something I haven't tried

The reproducible example (not minimal) I can suggest is to use the
submitted file.

ftp://CRAN.R-project.org/incoming/archive/HH_3.1-38.tar.gz

On my windows machine

R CMD check --as-cran HH_3.1-38.tar.gz
halts with
> BB <- likert(tmp[2:6,], box.width=unit(.4,"cm"), positive.order=TRUE)
Error in apply(x, 3:ldx, function(x) list(x)) :
  'MARGIN' does not match dim(X)
Calls: likert ... as.MatrixList -> as.MatrixList.array -> lapply -> apply
Execution halted

This is wrong.  That problem was in 3.1-37 and is why I needed a new version.
I repaired that problem. Running interactively, that command succeeds
on my machine.

R CMD check --as-cran --run-dontrun HH_3.1-38.tar.gz
halts with
> tmp.data <- confintervaldata()
Error in confintervaldata() : could not find function "confintervaldata"
Execution halted

That is wrong.  confintervaldata is in the NAMESPACE.
Running interactively, that command succeeds.
I added an ls("package:HH") ## yes I spelled it correctly
and the confinervaldata is missing from the list.  Again, it is in the
NAMESPACE for the generated executable package.


On the CRAN machines, neither of these problems appeared.  Instead
they found a different error
from code analysis, not from an execution failure.  I don't understand
why I didn't get that issue on
my machine when I used --as-cran.  The repair is in 3.1-39, which I
haven't sent in yet.
The repair is to replace
class(xxx) == "try-error"
with
"try-error" %in% class(xxx)

Please let me know if you see these same problems, or if you can think
of something else to try.

Rich


On Sun, Dec 8, 2019 at 4:58 PM Duncan Murdoch  wrote:
>
> On 08/12/2019 3:14 p.m., Richard M. Heiberger wrote:
> > I am seeing this in
> >> version
> > _
> > platform   x86_64-w64-mingw32
> > arch   x86_64
> > os mingw32
> > system x86_64, mingw32
> > status Under development (unstable)
> > major  4
> > minor  0.0
> > year   2019
> > month  12
> > day05
> > svn rev77528
> > language   R
> > version.string R Under development (unstable) (2019-12-05 r77528)
> > nickname   Unsuffered Consequences
> >
> > I also saw this in 2019-12-03 r77513
> >
> >
> > In my interactive use I set
> >> Sys.setenv("_R_CLASS_MATRIX_ARRAY_"="true")
> > to match what --as-cran does for class(matrix(1))
> >
> > There are two problems, unrelated I think.
> >
> > 1. I have an example which works correctly in interactive use and which
> > shows an error under R CMD check.  The error message is the one we now 
> > expect
> > when class(matrix(1)) is just "matrix".  The error should not be
> > triggered when the class
> > is c("matrix","array") >
> >
> > 2. I export many functions.  Several are not handled correctly during
> > R CMD check testing.
> > They appear in the NAMESPACE in the source, and also in both the
> > Rcheck 00_pkg_src and the Rcheck built package.
> > Yet, when those functions are called during the testing of the
> > examples, they aren't visible.
> > An ls() call inserted into the \examples{} section does not include them.
>
> ls() wouldn't normally see functions exported from packages.  You'd need
> ls("package:foo") to see the exports from package foo, and that only
> works after attaching the package.  But examples should be running with
> your package attached during testing, so if that's what you really
> meant, then you do have a problem.
>
> > The functions are visible and work correctly during interactive use.
> >
> >
> > I am running a WIndows 10 system inside a Parallels Virtual Machine on
> > a Macintosh.
> >
> > Has anyone else seen similar misbehavior?
> > Or can suggest a repair?
>
> Not seen this, and can't suggest a repair without seeing a reproducible
> example.
>
> Duncan

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

[R-pkg-devel] inconsistent behavior between R CMD check and interactive use

[Richard M. Heiberger]

I am seeing this in
> version
   _
platform   x86_64-w64-mingw32
arch   x86_64
os mingw32
system x86_64, mingw32
status Under development (unstable)
major  4
minor  0.0
year   2019
month  12
day05
svn rev77528
language   R
version.string R Under development (unstable) (2019-12-05 r77528)
nickname   Unsuffered Consequences

I also saw this in 2019-12-03 r77513


In my interactive use I set
> Sys.setenv("_R_CLASS_MATRIX_ARRAY_"="true")
to match what --as-cran does for class(matrix(1))

There are two problems, unrelated I think.

1. I have an example which works correctly in interactive use and which
shows an error under R CMD check.  The error message is the one we now expect
when class(matrix(1)) is just "matrix".  The error should not be
triggered when the class
is c("matrix","array")


2. I export many functions.  Several are not handled correctly during
R CMD check testing.
They appear in the NAMESPACE in the source, and also in both the
Rcheck 00_pkg_src and the Rcheck built package.
Yet, when those functions are called during the testing of the
examples, they aren't visible.
An ls() call inserted into the \examples{} section does not include them.
The functions are visible and work correctly during interactive use.


I am running a WIndows 10 system inside a Parallels Virtual Machine on
a Macintosh.

Has anyone else seen similar misbehavior?
Or can suggest a repair?

Rich

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

Re: [Rd] inappropriate warning in latticeExtra

[Richard M. Heiberger]

This problem is still present in

> version
   _
platform   x86_64-w64-mingw32
arch   x86_64
os mingw32
system x86_64, mingw32
status Under development (unstable)
major  4
minor  0.0
year   2019
month  12
day03
svn rev77513
language   R
version.string R Under development (unstable) (2019-12-03 r77513)
nickname   Unsuffered Consequences

Rich



On Sat, Jun 15, 2019 at 3:13 AM Deepayan Sarkar
 wrote:
>
> On Fri, Jun 14, 2019 at 6:42 PM Richard M. Heiberger  wrote:
> >
> > This is still not repaired in
> >  R version 3.6.0 Patched (2019-05-17 r76528)
> > > library(latticeExtra)
> > >  a <- xyplot(1 ~ 1)
> > > c(a,a)
> > Warning message:
> > In formals(fun) : argument is not a function
> >
> > Can we have it in R-3.6.1 that Peter just announced?
>
> Sorry I have been neglecting this (and some lattice bugs as well). I
> should get time to work on this after mid-July.
>
> -Deepayan
>
> >
> > Rich
> >
> > On Mon, Apr 2, 2018 at 4:08 AM Deepayan Sarkar
> >  wrote:
> > >
> > > On Fri, Mar 23, 2018 at 7:58 AM, Richard M. Heiberger  
> > > wrote:
> > > > The warning message in the last line of this email is incorrect.
> > > > This is behavior which Duncan Murdoch labeled a bug in
> > > >https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html
> > >
> > > Yes, sorry, this has been fixed in the r-forge sources for a while
> > > now, but I haven't had the time to finish up some other fixes and push
> > > an update to CRAN.
> > >
> > > Hopefully over the summer break.
> > >
> > > Regards,
> > > -Deepayan
> > >
> > >
> > > > This is a fresh install of R-devel (2018-03-21 r74436)
> > > >
> > > >
> > > >
> > > >
> > > > R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered 
> > > > Consequences"
> > > > Copyright (C) 2018 The R Foundation for Statistical Computing
> > > > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > > >
> > > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > > You are welcome to redistribute it under certain conditions.
> > > > Type 'license()' or 'licence()' for distribution details.
> > > >
> > > >   Natural language support but running in an English locale
> > > >
> > > > R is a collaborative project with many contributors.
> > > > Type 'contributors()' for more information and
> > > > 'citation()' on how to cite R or R packages in publications.
> > > >
> > > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > > 'help.start()' for an HTML browser interface to help.
> > > > Type 'q()' to quit R.
> > > >
> > > >> library(latticeExtra)
> > > > Error in library(latticeExtra) :
> > > >   there is no package called ‘latticeExtra’
> > > >> install.packages("latticeExtra")
> > > > Warning in install.packages("latticeExtra") :
> > > >   'lib = "C:/Program Files/R/R-devel/library"' is not writable
> > > > --- Please select a CRAN mirror for use in this session ---
> > > > also installing the dependency ‘RColorBrewer’
> > > >
> > > > Warning: unable to access index for repository
> > > > http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
> > > >   cannot open URL
> > > > 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
> > > > trying URL 
> > > > 'https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
> > > > Content type 'application/zip' length 55444 bytes (54 KB)
> > > > downloaded 54 KB
> > > >
> > > > trying URL 
> > > > 'https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
> > > > Content type 'application/zip' length 2191524 bytes (2.1 MB)
> > > > downloaded 2.1 MB
> > > >
> > > > package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
> > > > package ‘latticeExtra’ successfully unpacked and MD5 sums checked
> > > >
> > > > The downloaded binary packages are in
> > > > 
> > > > C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
> > > >> library(latticeExtra)
> > > > Loading required package: lattice
> > > > Loading required package: RColorBrewer
> > > >> a <- xyplot(1 ~ 1)
> > > >> c(a,a)
> > > > Warning message:
> > > > In formals(fun) : argument is not a function
> > > >>
> > > >
> > > > __
> > > > R-devel@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] inappropriate warning in latticeExtra

[Richard M. Heiberger]

Yes. You identified it a while ago and Deepayan wrote that he fixed it on
r-forge a year ago.  It still isn't on cran.

On Fri, Jun 14, 2019 at 16:04 Duncan Murdoch 
wrote:

> On 14/06/2019 9:12 a.m., Richard M. Heiberger wrote:
> > This is still not repaired in
> >   R version 3.6.0 Patched (2019-05-17 r76528)
> >> library(latticeExtra)
> >>   a <- xyplot(1 ~ 1)
> >> c(a,a)
> > Warning message:
> > In formals(fun) : argument is not a function
> >
> > Can we have it in R-3.6.1 that Peter just announced?
>
> That looks like a bug in the latticeExtra package, not in base R.  In
> particular, the latticeExtra:::c.trellis function appears to be trying
> to take the formals of NULL, and that's why you get the warning.
>
> Duncan Murdoch
>
> >
> > Rich
> >
> > On Mon, Apr 2, 2018 at 4:08 AM Deepayan Sarkar
> >  wrote:
> >>
> >> On Fri, Mar 23, 2018 at 7:58 AM, Richard M. Heiberger 
> wrote:
> >>> The warning message in the last line of this email is incorrect.
> >>> This is behavior which Duncan Murdoch labeled a bug in
> >>> https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html
> >>
> >> Yes, sorry, this has been fixed in the r-forge sources for a while
> >> now, but I haven't had the time to finish up some other fixes and push
> >> an update to CRAN.
> >>
> >> Hopefully over the summer break.
> >>
> >> Regards,
> >> -Deepayan
> >>
> >>
> >>> This is a fresh install of R-devel (2018-03-21 r74436)
> >>>
> >>>
> >>>
> >>>
> >>> R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered
> Consequences"
> >>> Copyright (C) 2018 The R Foundation for Statistical Computing
> >>> Platform: x86_64-w64-mingw32/x64 (64-bit)
> >>>
> >>> R is free software and comes with ABSOLUTELY NO WARRANTY.
> >>> You are welcome to redistribute it under certain conditions.
> >>> Type 'license()' or 'licence()' for distribution details.
> >>>
> >>>Natural language support but running in an English locale
> >>>
> >>> R is a collaborative project with many contributors.
> >>> Type 'contributors()' for more information and
> >>> 'citation()' on how to cite R or R packages in publications.
> >>>
> >>> Type 'demo()' for some demos, 'help()' for on-line help, or
> >>> 'help.start()' for an HTML browser interface to help.
> >>> Type 'q()' to quit R.
> >>>
> >>>> library(latticeExtra)
> >>> Error in library(latticeExtra) :
> >>>there is no package called ‘latticeExtra’
> >>>> install.packages("latticeExtra")
> >>> Warning in install.packages("latticeExtra") :
> >>>'lib = "C:/Program Files/R/R-devel/library"' is not writable
> >>> --- Please select a CRAN mirror for use in this session ---
> >>> also installing the dependency ‘RColorBrewer’
> >>>
> >>> Warning: unable to access index for repository
> >>> http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
> >>>cannot open URL
> >>> 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
> >>> trying URL '
> https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
> >>> Content type 'application/zip' length 55444 bytes (54 KB)
> >>> downloaded 54 KB
> >>>
> >>> trying URL '
> https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
> >>> Content type 'application/zip' length 2191524 bytes (2.1 MB)
> >>> downloaded 2.1 MB
> >>>
> >>> package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
> >>> package ‘latticeExtra’ successfully unpacked and MD5 sums checked
> >>>
> >>> The downloaded binary packages are in
> >>>
> C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
> >>>> library(latticeExtra)
> >>> Loading required package: lattice
> >>> Loading required package: RColorBrewer
> >>>> a <- xyplot(1 ~ 1)
> >>>> c(a,a)
> >>> Warning message:
> >>> In formals(fun) : argument is not a function
> >>>>
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] inappropriate warning in latticeExtra

[Richard M. Heiberger]

This is still not repaired in
 R version 3.6.0 Patched (2019-05-17 r76528)
> library(latticeExtra)
>  a <- xyplot(1 ~ 1)
> c(a,a)
Warning message:
In formals(fun) : argument is not a function

Can we have it in R-3.6.1 that Peter just announced?

Rich

On Mon, Apr 2, 2018 at 4:08 AM Deepayan Sarkar
 wrote:
>
> On Fri, Mar 23, 2018 at 7:58 AM, Richard M. Heiberger  wrote:
> > The warning message in the last line of this email is incorrect.
> > This is behavior which Duncan Murdoch labeled a bug in
> >https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html
>
> Yes, sorry, this has been fixed in the r-forge sources for a while
> now, but I haven't had the time to finish up some other fixes and push
> an update to CRAN.
>
> Hopefully over the summer break.
>
> Regards,
> -Deepayan
>
>
> > This is a fresh install of R-devel (2018-03-21 r74436)
> >
> >
> >
> >
> > R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered 
> > Consequences"
> > Copyright (C) 2018 The R Foundation for Statistical Computing
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> >   Natural language support but running in an English locale
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> >> library(latticeExtra)
> > Error in library(latticeExtra) :
> >   there is no package called ‘latticeExtra’
> >> install.packages("latticeExtra")
> > Warning in install.packages("latticeExtra") :
> >   'lib = "C:/Program Files/R/R-devel/library"' is not writable
> > --- Please select a CRAN mirror for use in this session ---
> > also installing the dependency ‘RColorBrewer’
> >
> > Warning: unable to access index for repository
> > http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
> >   cannot open URL
> > 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
> > trying URL 
> > 'https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
> > Content type 'application/zip' length 55444 bytes (54 KB)
> > downloaded 54 KB
> >
> > trying URL 
> > 'https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
> > Content type 'application/zip' length 2191524 bytes (2.1 MB)
> > downloaded 2.1 MB
> >
> > package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
> > package ‘latticeExtra’ successfully unpacked and MD5 sums checked
> >
> > The downloaded binary packages are in
> > 
> > C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
> >> library(latticeExtra)
> > Loading required package: lattice
> > Loading required package: RColorBrewer
> >> a <- xyplot(1 ~ 1)
> >> c(a,a)
> > Warning message:
> > In formals(fun) : argument is not a function
> >>
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [R-pkg-devel] Trying to work around missing functionality

[Richard M. Heiberger]

Does this solve the problem?

if (getRversion() >= '2.15.1')
  globalVariables(c('envroot'))

I keep this in file R/globals.R

I learned of this from John Fox's use in Rcmdr.

On Mon, Aug 27, 2018 at 8:28 PM, J C Nash  wrote:
> In order to track progress of a variety of rootfinding or optimization
> routines that don't report some information I want, I'm using the
> following setup (this one for rootfinding).
>
> TraceSetup <- function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
> # JN: Define globals here
>groot<-list(ifn=ifn, igr=igr, ftrace=ftrace, fn=fn, gr=gr, label="none")
>envroot <<- list2env(groot) # Note globals in FnTrace
>## This generates a NOTE that
>## TraceSetup: no visible binding for '<<-' assignment to ‘envroot’
> ##   envroot<-list2env(groot, parent=.GlobalEnv) # Note globals in FnTrace -- 
> this does NOT work
>## utils::globalVariables("envroot") # Try declaring here -- causes errors
> # end globals
>envroot
> }
>
> FnTrace <- function(x,...) {
>   # Substitute function to call when rootfinding
>   # Evaluate fn(x, ...)
> val <- envroot$fn(x, ...)
> envroot$ifn <- envroot$ifn + 1 # probably more efficient ways
> if (envroot$ftrace) {
>cat("f(",x,")=",val," after ",envroot$ifn," ",envroot$label,"\n")
> }
> val
> }
>
>
> Perhaps there are better ways to do this, but this does seem to work quite 
> well.
> It lets me call a rootfinder with FnTrace and get information on evaluations 
> of fn().
> (There's another gr() routine, suppressed here.)
>
> However, R CMD check gives a NOTE for
>
>   TraceSetup: no visible binding for global variable ‘envroot’
>   Undefined global functions or variables:
> envroot
>
> The commented lines in TraceSetup suggest some of the things I've tried. 
> Clearly I don't
> fully comprehend how R is grinding up the code, but searches on the net seem 
> to indicate
> I am far from alone. Does anyone have any suggestion of a clean way to avoid 
> the NOTE?
>
> JN
>
> __
> 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

[Rd] inappropriate warning in latticeExtra

[Richard M. Heiberger]

The warning message in the last line of this email is incorrect.
This is behavior which Duncan Murdoch labeled a bug in
   https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html

This is a fresh install of R-devel (2018-03-21 r74436)




R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered Consequences"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(latticeExtra)
Error in library(latticeExtra) :
  there is no package called ‘latticeExtra’
> install.packages("latticeExtra")
Warning in install.packages("latticeExtra") :
  'lib = "C:/Program Files/R/R-devel/library"' is not writable
--- Please select a CRAN mirror for use in this session ---
also installing the dependency ‘RColorBrewer’

Warning: unable to access index for repository
http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
  cannot open URL
'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
trying URL 
'https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
Content type 'application/zip' length 55444 bytes (54 KB)
downloaded 54 KB

trying URL 
'https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
Content type 'application/zip' length 2191524 bytes (2.1 MB)
downloaded 2.1 MB

package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
package ‘latticeExtra’ successfully unpacked and MD5 sums checked

The downloaded binary packages are in

C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
> library(latticeExtra)
Loading required package: lattice
Loading required package: RColorBrewer
> a <- xyplot(1 ~ 1)
> c(a,a)
Warning message:
In formals(fun) : argument is not a function
>

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

Re: [R-pkg-devel] Latex error during compilation

[Richard M. Heiberger]

Sounds like a missing "}".
Which could mean the brace is inside quotes or following a "%"

On Tue, Mar 6, 2018 at 09:17 michael tsagris via R-package-devel <
r-package-devel@r-project.org> wrote:

>
>
>
> -- Forwarded message --
> From: michael tsagris 
> To: "r-package-devel@r-project.org" 
> Cc:
> Bcc:
> Date: Tue, 6 Mar 2018 04:21:16 + (UTC)
> Subject: Latex error during compilation
> Can somebody please tell me how to fix this error? the only I thing I
> change in my computer is the latex. I updated miktext and texmaker. And
> here I am.
> LaTeX errors when creating PDF version.
> This typically indicates Rd problems.
> LaTeX errors found:
> ! File ended while scanning use of \HeaderA.
> 
> \par
> <*> D:/temp/RtmpA5snrO/Rd2pdf122d81cab6b64/Rd2.tex
>
> ! Emergency stop.
> <*> D:/temp/RtmpA5snrO/Rd2pdf122d81cab6b64/Rd2.tex
>
> *** (job aborted, no legal \end found)
>
> !  ==> Fatal error occurred, no output PDF file produced!
> * checking PDF version of manual without hyperrefs or index ... ERROR
> * DONE
> [[alternative HTML version deleted]]
>
>
>
>
> -- Forwarded message --
> From: michael tsagris via R-package-devel 
> To: "r-package-devel@r-project.org" 
> Cc:
> Bcc:
> Date: Tue, 6 Mar 2018 04:21:16 +
> Subject: [R-pkg-devel] Latex error during compilation
> __
> 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: [Rd] debuggingState() analogous to tracingState() ?

[Richard M. Heiberger]

Interesting timing.  I could have used this additional control
yesterday in class.

I am teaching a graduate Statistical Computing class.  Last night I
went through the symbolic deriviatives (the deriv and D functions) in
Section 9.6 of the Blue Book.  The D function is recursive.  I
illustrated its behavior with debug(D) and then studied the statement
D(expression(x^2+4), x)

At each step the console displays the entire switch() statement.  And
inside ESS the entire switch statement in the derivative.R buffer is
highlighted.  That is too much redundancy.  I would like to have the
.R buffer highlighted and maybe a truncated version of the statement
displayed in the *R* (console) buffer.  I am thinking of a trunctation
similar to what C-c C-c in ESS does when it sends over a function
definition.  Somewhere around the third or fourth level of recursion I
would truncate it even further.  When investigating
   3*x^2 + 4*x^5
It would be nice to see the detail of several levels of recursion for
the 3*x^2 term and turn off the debug/trace behavior of the 4*x^5
term, with the debug/trace beahvior automatically coming back on when
the two terms are merged.


I discovered I would like an additional stop during debug.

Here is a simple function to illustrate.

simple - function(x) {
   y - x + x
   2*y
}

debug stops before the 'y - x+x 'and again before the '2*y' is
evaluated and I can do regular browser investigations.  When I hit
enter, I want it to stop again after 2*y has been evaluated and before
it returns to the console.  I would like to investigate the result and
then go back and investigate the intermediate variables with the
result in view.  Obviously I can redefine my own function to

redesignedsimple - function(x) {
   y - x + x
   z - 2*y
   z
}

but doing that to a function inside a NAMESPACE is very difficult to
get right.


Rich

On Thu, Oct 2, 2014 at 10:55 AM, Martin Maechler
maech...@stat.math.ethz.ch wrote:
 We have had some conversation within R core,
 lead by Duncan Murdoch and me, about a proposal
 to extend  the current  tracingState() functionality
 by something tentatively called debuggingState().

 Duncan has allowed me to copy the previous conversation
 (after very minor editing):

 The following is quite technical and assumes you know more about
 R's debug()ing and trace()ing than an estimated 99.9% of the R users:

 Duncan Murdoch murdoch.dun...@gmail.com
 on Thu, 2 Oct 2014 07:19:34 -0400 writes:

   On 02/10/2014, 6:36 AM, Martin Maechler wrote:
   Duncan Murdoch murdoch.dun...@gmail.com
   on Thu, 2 Oct 2014 05:41:00 -0400 writes:
  
On 02/10/2014, 5:17 AM, Martin Maechler wrote:
Martin Maechler maech...@stat.math.ethz.ch
on Sat, 27 Sep 2014 22:55:21 +0200 writes:
   
 It would be really nice to temporarily disable debugging similar to
 tracingState() being able to turn of trace()ing.
   
 In eval.c  the corresponding C code would be used as the  
 tracingState()
 analogue is used.
   
 [...]
 ???
   
It seems to work ok, the few cases I've tried.
   
I wonder a bit about the R / C interface.
Using an extra function  debuggingState() seems a bit of a
waste, and I was thinking of enhancing
tracingState() from a 1-argument to a 2-argument form.
   
something like
   
tracingState - function(on = NULL, debug = on)
.Internal(traceOnOff(on, debug))
   
but I don't see how to keep usages such as
   
  on - tracingState(FALSE)   # turn it off QUICKLY (via a 
 .Internal)
  if(on) {
on.exit(tracingState(TRUE)) # restore on exit, keep off during 
 trace

  }
   
working back compatibly.
   
We could think of tracingState() only returning length one when
called with one argument, and returning length two when called
with a second argument... but that seems messy.
   
If nobody has a better idea, I'd commit a new   debuggingState()
function which is very much parallel to  tracingState().
  
It's hard to comment on this, because I don't know exactly what
behaviour is controlled by the debugging flag.
  
   Good point.  The flag, accessed via RDEBUG(.), is used in quite a few 
 places,
   and the intent and my experiments have replaced
  
RDEBUG(.)
   by   RDEBUG(.)  R_current_debug_state()
  
   in some places, but not in most places.
  
Will it cause an
explicit call to browser() to be a no-op, or does it just control breaks
triggered by entry into a function that has been marked by debug()?
  
   What would you want?  Probably the latter, right?
   With my use case below, however, I could argue I'd even want  browser()
   to be a no-op in that case.  It is not so important to me.
  
What is the effect of a call to a function marked with debugOnce()?
  
   Good question.  Here my code was such that the function would also
   not have been debugged.
   But of course, that is open for debate,  and I am 

[Rd] warning in lattice key function

[Richard M. Heiberger]

## this example shows a problem in key.
tmp - data.frame(y=rnorm(10), g=rep(ordered(c(A,B)), 5))
bwplot(y ~ g, data=tmp,
   key=list(
 text=list(c(A,B), col=c(blue,red)),
 points=list(pch=c(17, 16), col=c(blue,red)),
 space=top, columns=2, border=TRUE,
 title=Treatment, cex.title=.9
 )
   )
## The example works without warning messages in 2.15.1.
## I first detected the problem in
# R Under development (unstable) (2012-07-24 r59961) ## windows
# R Under development (unstable) (2012-08-02 r60091) ## macintosh
## The problem still exists in
## R Under development (unstable) (2012-08-13 r60245) -- Unsuffered
Consequences
## downloaded from lib.stat.cmu.edu Wed Aug 15 2012 11PM EST


 tmp - data.frame(y=rnorm(10), g=rep(ordered(c(A,B)), 5))
 bwplot(y ~ g, data=tmp,
+key=list(
+  text=list(c(A,B), col=c(blue,red)),
+  points=list(pch=c(17, 16), col=c(blue,red)),
+  space=top, columns=2, border=TRUE,
+  title=Treatment, cex.title=.9
+  )
+)
Warning messages:
1: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
2: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
3: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
4: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
5: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
 version
   _
platform   i386-w64-mingw32
arch   i386
os mingw32
system i386, mingw32
status Under development (unstable)
major  2
minor  16.0
year   2012
month  08
day13
svn rev60245
language   R
version.string R Under development (unstable) (2012-08-13 r60245)
nickname   Unsuffered Consequences


[[alternative HTML version deleted]]

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

Re: [Rd] [R] any updates w.r.t. lapply, sapply, apply retaining classes

[Richard M. Heiberger]

Mike,

On time classes specifically, the lubridate package
with documentation
Garrett Grolemund, Hadley Wickham (2011).
 Dates and Times Made Easy with lubridate.
 Journal of Statistical Software, 40(3), 1-25.
 http://www.jstatsoft.org/v40/i03/.

solves many confusion problems.  Does it handle the problems you are
reporting?

Rich



On Thu, Nov 3, 2011 at 7:49 PM, Mike Williamson this.is@gmail.comwrote:

 Hi Joshua,

Thank you for the input!

I agree that it is non-trivial to solve the cases you  I have posed.
  However, I would wholeheartedly support having an error spit back for any
 function that does not explicitly support a class.  In this case, if I
 attempt to do   sapply(x, class), and 'x' is of class difftime, then I
 should receive an error sapply cannot function upon class 'difftime' .
  Why do I take this stance?  There are at least 2 strong reasons:

   - Most importantly, an incorrect answer is far more dangerous than no
   answer.  E.g., if I ask what is 3 + 3?, I would far prefer to receive
 I
   don't know than 5.  The former lets me know I need to choose another
   path, the latter mistakenly makes me think I have an answer, when I do
 not,
   and I continue with analyses on the assumption that answer is correct.
  In
   the case of dates, this happens often.  E.g., is the numeric that is
   returned from sapply, for instance, the # of seconds since 1970-01-01, or
   the number of days since 1970-01-01.  This depends upon how 'R'
 internally
   attempts to fix any incongruities.
   - But also very significantly, an error will get me in the habit of
   avoiding any marginalized class types.  I keep thinking, for instance,
 that
   I can use the Dates class, since 'R' says that it supports them.  But
 if
   I got into the habit of converting all dates into numerics myself
   beforehand (maybe counting the number of seconds from 1970-01-01, since
   that seems a magic date), then I would be guaranteed that a function will
   either (a) cause an error (e.g., if I try a character function on it), or
   (b) function properly.  However, since I don't overtly receive errors
 when
   attempting to use dates (or difftimes, or factors, or whatever), I keep
   using them, instead of relying solely upon the true  trusted classes.
  - the trickiest here is really factors.  Factors are, by most
  accounts, considered a core class.  In some cases, you can only use
  factors.  E.g., when you want some sort of ordinal categorical
 variable.
   Therefore, the fact that factors also barf similarly to other
 classes like
  difftime (albeit much more rarely), is especially dangerous.

There are, of course, habits that we can create to make ourselves
 better programmers, and I will recognize that I can improve.  However, this
 issue of functions generating wrong answers is such a *huge* problem with
 'R', and other languages are catching up to 'R' so quickly, as far as their
 capability to handle higher level math, that this issue is making 'R' a
 less desirable language to use, as time progresses.  I don't mean to claim
 that my opinion is the end-all-be-all, but I would like to hear others
 chime in, whether this is a large concern, or whether there is a very small
 minority of folks impacted by it.

  Regards,
 Mike

 ---
 XKCD http://www.xkcd.com



 On Thu, Nov 3, 2011 at 2:51 PM, Joshua Wiley jwiley.ps...@gmail.com
 wrote:

  Hi Mike,
 
  This isn't really an answer to your question, but perhaps will serve
  to continue discussion.  I think that there are some fundamental
  issues when working special classes.  As a thought example, suppose I
  wrote a class, posreal, which inherits from the numeric class.  It
  is only valid for positive, real numbers.  I use it in a package, but
  do not develop methods for it.  A user comes along and creates a
  vector, x that is a posreal.  Then tries: mean(x * -3).  Since I never
  bothered to write a special method for mean for my class, R falls back
  to the inherited numeric, but gives a value that is clearly not valid
  for posreal.  What should happen?  S3 methods do not really have
  validation, so in principle, one could write a function like:
 
  f - function(x) {
   vclass - class(x)
   res - mean(x)
   class(res) - vclass
   return(res)
  }
 
  which retains the appropriate class, but in name only.  R core
  cannot possibly know or imagine all classes that may be written that
  inherit from more basic types but with possible special aspects and
  requirements.  I think the inherited is considered to be more generic
  and that is returned.  It is usually up to the user to ensure that the
  function (whose methods were not specific to that special class but
  the inherited) is valid for that class and can manually convert it
  back:
 
  res - as.posreal(res)
 
  What about lapply and sapply?  Neither are generic or have 

[Rd] Rd cross-references ... WARNING in R-2.10.*

[RICHARD M. HEIBERGER]

I have observed a difference in behavior of R CMD check in older R vs R-2.10.x
on windows.
* using R version 2.10.0 (2009-10-26)
* using R version 2.10.1 RC (2009-12-14 r50718)

2.10 seems to be looking on the internet for crossreferenced packages.
I am not sure why it is looking.  The string pkg is not in any of
the Rd files.  I think it is not finding any CRAN sites because I am
currently behind a firewall.  I have attempted several variations of

R --internet2 CMD check --no-examples --no-latex packagename

and no position that I placed the keyword --internet2 was valid.


* checking Rd metadata ... OK
* checking Rd cross-references ... WARNING
Warning: unable to access index for repository http://cran.r-project.org/src/con
trib
Warning: unable to access index for repository http://www.omegahat.org/R/src/con
trib
Warning: unable to access index for repository http://www.bioconductor.org/packa
ges/2.5/bioc/src/contrib
Warning: unable to access index for repository http://www.bioconductor.org/packa
ges/2.5/data/annotation/src/contrib
Warning: unable to access index for repository http://www.bioconductor.org/packa
ges/2.5/data/experiment/src/contrib
Unknown package(s) 'pkg' in Rd xrefs
* checking for missing documentation entries ... WARNING


By comparison

* using R version 2.8.0 (2008-10-20)

* checking Rd cross-references ... OK
* checking for missing documentation entries ... WARNING



If my diagnosis looks correct, can you suggest what is triggering
the search on the internet?  Can you give a more specific warning message?
Is there a way to force internet2 in the R CMD check setting?

Thanks

Rich

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

[Rd] newly introduced lattice bug

[Richard M. Heiberger]

 library(lattice)
 xyplot(rnorm(10) ~ rnorm(10) | factor(1:10), layout=c(2,3))
 version
   _ 
platform   i386-pc-mingw32   
arch   i386  
os mingw32   
system i386, mingw32 
status RC
major  2 
minor  4.0   
year   2006  
month  09
day27
svn rev39543 
language   R 
version.string R version 2.4.0 RC (2006-09-27 r39543)
 


This was downloaded two minutes ago from the CRAN page
http://cran.us.r-project.org/bin/windows/base/rtest.html
dated
Last build: 2006-09-29, by Duncan Murdoch


The bug is that 2.4.0 RC displays 12 panels, with the incorrect top two panels
on the second page being copies of the correct top two panels on the first page.

I just noticed this in R version 2.4.0 beta (2006-09-20 r39421)
and immediately got a newer version of R before reporting it.

R-2.3.1 displays the correct 10 panels.

Rich

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

[Rd] problems in installing packages with R version 2.4.0 alpha (2006-09-05 r39134)

[Richard M. Heiberger]

I just downloaded the windows version 
 R version 2.4.0 alpha (2006-09-05 r39134)

1. When I downloaded the packages, the following two were not found.
 utils:::menuInstallPkgs()
--- Please select a CRAN mirror for use in this session ---
dependency ''fCalendar'' is not available

dependency ''SparseM'' is not available


I am not sure which other packages depend on these.


2. Of the others, several didn't install cleanly

package 'mlbench' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation 'C:\Program Files\R\R-
2.4.0alpha\library\file41bb5af1\mlbench' to 'C:\Program 
Files\R\R-2.4.0alpha\library\mlbench'
package 'tseries' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation 'C:\Program 
Files\R\R-2.4.0alpha\library\file305e124
\tseries' to 'C:\Program Files\R\R-2.4.0alpha\library\tseries'
package 'DAAG' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation 'C:\Program Files\R\R-
2.4.0alpha\library\file491c440d\DAAG' to 'C:\Program 
Files\R\R-2.4.0alpha\library\DAAG'
package 'acepack' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation 'C:\Program Files\R\R-
2.4.0alpha\library\file767d7a5a\acepack' to 'C:\Program 
Files\R\R-2.4.0alpha\library\acepack'
package 'rcom' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation 'C:\Program Files\R\R-
2.4.0alpha\library\file58784b40\rcom' to 'C:\Program 
Files\R\R-2.4.0alpha\library\rcom'


I reinstalled all five from the local zip files that were downloaded as part of 
the above
installation, and four worked and one didn't.
I needed to reinstall mlbench a third time and this time it worked.

This type of problem frequently happens when I download a new version of R.


3. rgl is still not working in Windows

package 'rgl' successfully unpacked and MD5 sums checked

 library(rgl)
Error in dyn.load(x, as.logical(local), as.logical(now)) : 
unable to load shared library 
'C:/PROGRA~1/R/R-24~1.0AL/library/rgl/libs/rgl.dll':
  LoadLibrary failure:  The specified procedure could not be found.

Error: package/namespace load failed for 'rgl'



Therefore the Rcmdr 3-d graphics isn't working.


Rich

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

Re: [Rd] Two submitted packages

[Richard M. Heiberger]

From: Prof Brian Ripley
 There is no '2.4.1', and your R-devel is not very recent.

Apologies on the typo and the two-week old 2.4.0dev.

I just downloaded
   version 2.4.0 Under development (unstable) (2006-09-04 r39086)


1.
 You set cpv$clip - off and the internal code assumes that it is logical 
 (as the message says).  I can't find any documentation to support your 
 code: if there is some please report it to the maintainer of grid (Paul 
 Murrell).

The documentation for off comes from ?viewport that is part of 2.4.0dev.
 installed.packages()[grid,]
   PackageLibPath 
grid C:/PROGRA~1/R/R-24~1.0DE/library 
   Version   Priority 
   2.4.0 base 
Bundle   Contains 
NA NA 
   DependsImports 
   grDevices NA 
  Suggests  Built 
 lattice2.4.0 

clip
One of on, inherit, or off, indicating whether to clip to the
extent of this viewport, inherit the clipping region from the parent
viewport, or turn clipping off altogether. For back-compatibility, a
logical value of TRUE corresponds to on and FALSE corresponds to
inherit.

The above description of clip is identical to the description in
?viewport in the released 2.3.1.


I still get the same error in 2.4.0dev that did not appear in 2.3.1
and it still looks to me like this is an equally valid statement in both
versions of R.
  Error in grid.Call.graphics(L_setviewport, pvp, TRUE) : 
  LOGICAL() can only be applied to a 'logical', not a 'character'
  

I think something needs to be changed to make the documentation and the
program consistent.  I like the documentation, with the three options
for clipping, and hope to see the program changed to match it.


2.
  ## Question 1.  How do I place a trace() on grid.Call.graphics to make
  ## it stop and give me a traceback.
 Not sure why you want to do that, as traceback() works here.
... as does options(error=recover).

I was interested in the argument
trace(..., exit=recover)
I see now that
options(error=recover)
does exactly what I want.  That is the incantation I was looking for.
Thank you.

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

[Rd] enhancement request for labeling help windows in Windows

[Richard M. Heiberger]

I would like to make a formal request for an enhancement.

The default help for RGui in 2.4.0dev seems to be the .chm format
outside of the RGui frame.  Previously the default help was individual
windows inside the RGui frame.  Every package in R has its own help
file and all of them are labeled identically as Help by Windows.
The labels appear in the title of the window, in the task bar, and in
the alt-tab menu.

The request is to give each a unique name, for example
R Help --- base
R Help --- grid
R Help --- lattice

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

Re: [Rd] enhancement request for labeling help windows in Windows

[Richard M. Heiberger]

I am looking at the HTML Help Workshop which I got from wherever
your website told me to get it.

There is no documentation in the material I have.  My guess is that one
of the variables in the file  c:/Program Files/HTML Help 
Workshop/include/htmlhelp.h
needs to be changed.  My first guess is the line
LPCTSTR pszCaption;  // IN/OUT: Window title
although how to change the value of pszCaption is not at all obvious.

I opened up the .chm files in emacs for other applications and they all
have a string buried inside that contains the name that appears on the window.

Rich

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

Re: [Rd] Two submitted packages

[Richard M. Heiberger]

Deepayan wrote:

  xyplot(y ~ x | a,
 data=tmp, ylim=c(1.5,4.5),
 par.settings = list(clip = list(panel = off)),
 layout=c(2,2))
 
 I'm curious to know why this functionality is not enough.


## 1. Here is a more realistic example.

tmp - data.frame(x=1:5, y=1:5, a=factor(c(1,1,1,1,1), levels=1:4))

## This gives what I want.
## It looks like the upViewport/downViewport sequence is the control I
## should be using.  If this is a stable sequence, it answers my needs.
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(...) {
  panel.xyplot(...)
upViewport()
downViewport(trellis.vpname(panel,
row = 1, column = 1, clip.off = TRUE))
  panel.axis(side=right, outside=TRUE)
   },
   layout=c(2,2),
   main=right axis visible by control, points clipped by default)

## If I turned off clipping at the top, I would get the unwanted points
## plotted outside the figure region.
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   par.settings = list(clip = list(panel = off)),
   panel=function(...) {
  panel.xyplot(...)
  panel.axis(side=right, outside=TRUE)
   },
   layout=c(2,2),
   main=right axis visible by control, points not clipped)


## this is what happens if I don't do any control of clipping
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(...) {
  panel.xyplot(...)
  panel.axis(side=right, outside=TRUE)
   },
   layout=c(2,2),
   main=right axis invisible by clipping, points clipped by default)


## This doesn't work, but it illustrates the syntax I would like.
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(...) {
  panel.xyplot(...)
  panel.axis(side=right, outside=TRUE, clip=off)
   },
   layout=c(2,2),
   main=right axis visible by control, points clipped by default)




## 2
 Unfortunately, there is currently no easy way to find out which column
 and row the current panel occupies. I plan to make some changes before
 R 2.4.0 is released that should expose that information, so please try
 again in a few weeks.

The way I have been using is to back up the calling sequence and
use statements like
{
## This loop is needed because
##console usage has i=2,
##Rcmdr script window has i=5,
##Rcmdr justDoIt has i=20
for (i in seq(2, length=30)) {
  sf2 - sys.frame(i)
  column.tmp - try(get(column, pos=sf2), silent=TRUE)
  if (class(column.tmp) != try-error) break
}
if (class(column.tmp) == try-error)
  stop(panel.interaction2wt is too deeply nested in the system stack.)
row - get(row, pos=sf2)
column - get(column, pos=sf2)
cols.per.page - get(cols.per.page, pos=sf2)
rows.per.page - get(rows.per.page, pos=sf2)
  }

## A cleaner way would be preferable.  Will the above stay valid?  The
## need for a loop to find out how far up the calling sequence to go
## caught me by surprise.  I don't understand why generating commands
## the way Rcmdr does it should have an effect on the depth of the
## calling sequence.

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

Re: [Rd] Two submitted packages

[Richard M. Heiberger]

## This example runs in R 2.3.1 and does not run in R 2.4.1.  I am
## raising it here for two questions: one on how to debug functions
## inside a namespace, the other on how to control clipping.

tmp - data.frame(x=1:5, y=1:5, a=factor(c(1,1,1,1,1), levels=1:4))
xyplot(y ~ x,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(x,y, ...) {
 cpv - current.viewport()
 cpv$clip - off
 pushViewport(cpv)
 panel.xyplot(x, y, ...)
 popViewport()
   })

## R version 2.4.0 Under development (unstable) (2006-08-14 r38872)
## gives the error message
Error in grid.Call.graphics(L_setviewport, pvp, TRUE) : 
LOGICAL() can only be applied to a 'logical', not a 'character'


## Question 1.  How do I place a trace() on grid.Call.graphics to make
## it stop and give me a traceback.  I tried many variations of the
## command
##trace(grid:::grid.Call.graphics, exit=recover,
##  where=environment(grid:::grid.Call.graphics))
## None of them trapped the error and let me trace it.  What is the
## correct incantation?



## Question 2.  How do I control clipping from within a panel
## function?  In 2.3.1, both of the following statements run without
## error.  Neither of them turns clipping off.
##
## In 2.4.0, the off statement gives the error message above.  The
## FALSE statement runs without error, but it didn't turn clipping off.

xyplot(y ~ x | a,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(x,y, ...) {
 cpv - current.viewport()
 cpv$clip - off
 pushViewport(cpv)
 panel.xyplot(x, y, ...)
 popViewport()
   },
   layout=c(2,2))

xyplot(y ~ x | a,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(x,y, ...) {
 cpv - current.viewport()
 cpv$clip - FALSE
 pushViewport(cpv)
 panel.xyplot(x, y, ...)
 popViewport()
   },
   layout=c(2,2))


## ?viewport in 2.4.0 says
## clip
##
## One of on, inherit, or off, indicating whether to clip to the
## extent of this viewport, inherit the clipping region from the
## parent viewport, or turn clipping off altogether. For
## back-compatibility, a logical value of TRUE corresponds to on and
## FALSE corresponds to inherit.

## Notice that off is current and FALSE is back-compatible, and
## off is the value that causes the error.

## What is the correct way to turn off clipping?
## The way that I would like to use is something on the order of

xyplot(y ~ x | a,
   data=tmp, ylim=c(1.5,4.5),
   panel=function(x,y, ...) {
 panel.xyplot(x, y, ...,
  par.settings = list(clip = list(panel = off)))
   },
   layout=c(2,2))

## I believe par.settings is currently valid only in xyplot() and not
## valid in panel functions.  Is my understanding correct?  Can the
## behavior be changed?
##
## The following statement works correctly in both 2.3.1 and 2.4.0.
## This statement controls clipping for the entire xyplot, not just
## for the single statement within the panel function.

xyplot(y ~ x | a,
   data=tmp, ylim=c(1.5,4.5),
   par.settings = list(clip = list(panel = off)),
   layout=c(2,2))

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