Yes. An initial space does the trick. Thanks. J
On 2023-11-03 11:48, Serguei Sokol wrote:
Le 03/11/2023 à 15:54, J C Nash a écrit :
I've spent a couple of hours with an Rmarkdown document where I
was describing some spherical coordinates made up of a radius r and
some angles. I wanted to fix
I've spent a couple of hours with an Rmarkdown document where I
was describing some spherical coordinates made up of a radius r and
some angles. I wanted to fix the radius at 1.
In my Rmarkdown text I wrote
Thus we have `r = 1` ...
This caused failure to render with "unexpected =". I was
Thanks. That seems to be the issue. Also vincent's suggestion of checkRd.
JN
On 2023-10-22 10:52, Ivan Krylov wrote:
On Sun, 22 Oct 2023 10:43:08 -0400
J C Nash wrote:
\itemize{
\item{fnchk OK;}{ \code{excode} = 0;
\code{infeasible} = FALSE
I'm doing a major update of the optimx package and things were going relatively
smoothly until this weekend when files that have passed win-builder gave NOTEs
on r-devel for several manual (.Rd) files.
The NOTE is of the form
* checking Rd files ... NOTE
checkRd: (-1) fnchk.Rd:40-41: Lost
On 9/2/23 4:23 PM, Greg Hunt wrote:
The percent encoded characters appear to be valid in that URL, suggesting
that rejecting them is an error. That kind of error could occur when the
software processing them converts them back to a non-unicode character set.
On Sun, 3 Sep 2023 at 4:34 am, J C Nas
I'm posting this in case it helps some other developers getting build failure.
Recently package nlsr that I maintain got a message that it failed to build on
some platforms. The exact source of the problem is still to be illuminated,
but seems to be in knitr::render and/or pandoc or an
My nlsr package was revised mid-February. After CRAN approved it, I got a
message that it was "failing" M1Mac tests. The issue turned out to be ANOTHER
package that was being used in an example in a vignette. Because M1 does not
provide the IEEE 754 80 bit registers, a method in package minqa did
The important information is in the body of the man page for news(),
i.e., found by
?utils::news
and this explains why putting an "o" in front of a line clears the
NOTE. Once I realized that CRAN is running this, I could see the
"why". Thanks.
JN
On 2023-07-26 10:25, Duncan Murdoch wrote:
if there are plans to use NEWS for some purpose in
the future i.e., to actually track changes beyond package maintainer's
comments?
Cheers, and thanks again.
JN
On 2023-07-26 10:03, Ivan Krylov wrote:
В Wed, 26 Jul 2023 09:37:38 -0400
J C Nash пишет:
I'd like to avoid NOTEs if possible
In work on an upgrade to my optimx package, I added to my (plain text) NEWS
file.
The lines
VERSION 2023-06-25
o This is a MAJOR revision and overhaul of the optimx package and its
components.
o Fixed CITATION file based on R CMD check --as-cran complaints
regarding
In updating my nlsr package, I ran R CMD check --as-cran and got an error
that /usr/lib/R/doc/html/katex/katex.js was not found.
I installed the (large!) r-cran-katex. No joy.
katex.js was in /usr/share/R/doc/html/katex/ so I created a symlink. Then
I got katex-config.js not found (but in 1
Recently I updated my package nlsr and it passed all the usual checks and was
uploaded to CRAN. A few days later I got a message that I should "fix" my
package as it had failed in "M1max" tests.
The "error" was actually a failure in a DIFFERENT package that was used as
an example in a vignette.
FWIW: optimx::optimx is outdated and only there for legacy use.
Better to use the optimx::optimr() function for single solvers.
JN
On 2022-11-25 05:10, Ivan Krylov wrote:
В Fri, 25 Nov 2022 09:59:10 +
"ROTOLO, Federico /FR" пишет:
When submitting my package parfm, I get the following
I'd second Uwe's point. I was one of 31 signatories to first IEEE 754 (I didn't
participate in
the two more recent releases, as I already tore my hair out with the details of
low level
bit manipulations). Before the standard, porting code was truly a nightmare. We
did it
because we had to and
I think this is similar in nature (though not detail) to an issue raised
on StackOverflow where the OP used "x" in dot args and it clashed with the
"x" in a numDeriv call in my optimx package. I've got a very early fix (I
think), though moderators on StackOverflow were unpleasant enough to
delete
> On 12.06.2021 16:39, J C Nash wrote:
>> Two minor notes:
>>
>> 1) The Writing R Extensions manual, as far as I can determine, does not
>> inform package
>> developers that Makevars.win needs to be in the src/ subdirectory. I
>> followed the example
>
to install with "makevars.win", I
got a
WARNING on running a CHECK until I replaced it with "Makevars.win", i.e.,
Camel-case
name.
Do these observations merit edits in the manual?
JN
On 2021-06-11 11:16 a.m., J C Nash wrote:
> After some flailing around, discover
-06-10 9:37 a.m., Dirk Eddelbuettel wrote:
>
> On 10 June 2021 at 09:22, J C Nash wrote:
> | Thanks to help from Duncan Murdoch, we have extracted the nls()
> functionality to a package nlspkg and are building
> | an nlsalt package. We can then run nlspkg::AFunction() and
>
> [11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.1.0
>>
On 2021-06-10 9
Hi,
I'm mentoring Arkajyoti Bhattacharjee for the Google Summer of Code project
"Improvements to nls()".
Thanks to help from Duncan Murdoch, we have extracted the nls() functionality
to a package nlspkg and are building
an nlsalt package. We can then run nlspkg::AFunction() and
ymmetric.matrix
>>>> <https://rdrr.io/cran/matrixcalc/src/R/is.symmetric.matrix.R>, and
>>>> is.positive.definite
>>>> <https://rdrr.io/cran/matrixcalc/src/R/is.positive.definite.R>) and
>>> there
>>>> is only one function in post
I just downloaded the source matrixcalc package to see what it contained. The
functions
I looked at seem fairly straightforward and the OP could likely develop
equivalent features
in his own code, possibly avoiding a function call. Avoiding the function
call means NAMESPACE etc. are not
021 9:49 a.m., J C Nash wrote:
>> Another approach is to change the responsibility.
>>
>> My feeling is that tests in the TESTING package should be modifiable by the
>> maintainer of
>> the TESTED package, with both packages suspended if the two maintainers
>&
Another approach is to change the responsibility.
My feeling is that tests in the TESTING package should be modifiable by the
maintainer of
the TESTED package, with both packages suspended if the two maintainers cannot
agree. We
need to be able to move forward when legacy behaviour is outdated
Possibly the "old" site-library is not getting over-written. I had to
manually delete.
See https://www.mail-archive.com/r-help@r-project.org/msg259132.html
JN
On 2020-07-28 7:21 a.m., Dirk Eddelbuettel wrote:
>
> Hi Adelchi,
>
> On 28 July 2020 at 11:46, Adelchi Azzalini wrote:
> | When I
Are you sure you want to try to run R etc. under Wine?
- If you have Windows running, either directly or in a VM, you can run R there.
- If you have Windows and want to run R under some other OS, then set up a VM
e.g., Linux Mint, for that. I sometimes test R for Windows in a VirtualBox VM
for
I'm seeking some general advice about including vignettes in my packages,
which are largely for nonlinear estimation and function minimization
(optimization).
This means that my packages offer alternatives to many other tools, and the user
then has the chore of deciding which is appropriate. Bad
n...@gmail.com>> wrote:
>
> On 07/06/2019 12:32 p.m., William Dunlap wrote:
> > The length-condition-not-equal-to-one checks will cause R to shutdown
> > even if the code in a tryCatch().
>
> That's strange. I'm unable to reproduce it with my tries, and
FALSE FALSE FALSE FALSE FALSE
>>>
>>> The || operator works on length 1 Booleans. Since fval can be of
>> length
>>> greater than 1 at that point, the proper condition seems to be:
>>>
>>> any(is.infinite(fval)) || any(is.na(fval))
>> a little ty
LSE FALSE FALSE FALSE FALSE FALSE
>
> The || operator works on length 1 Booleans. Since fval can be of length
> greater than 1 at that point, the proper condition seems to be:
>
> any(is.infinite(fval)) || any(is.na(fval))
>
> Best regards,
>
> Sebastian
>
iolate some conditions e.g., character rather than
numeric etc.
JN
On 2019-06-07 8:44 a.m., J C Nash wrote:
> Uwe Ligges ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de
> Fri Jun 7 11:44:37 CEST 2019
>
> Previous message (by thread): [R-pkg-devel] try() in R CMD check --as-cran
&
After making a small fix to my optimx package, I ran my usual R CMD check
--as-cran.
To my surprise, I got two ERRORs unrelated to the change. The errors popped up
in
a routine designed to check the call to the user objective function. In
particular,
one check is that the size of vectors is
There is a quite well-developed but not terribly large C program
for conjugate gradients and similar approaches to optimization I would
like to wrap in a package for use in R. I would then build this into the
optimx package I maintain. I suspect that the approach may turn out to be
one of the most
have the same parent):
>
> ea <- TraceSetup_2(fn = function(x) x^2 - 2*x + 1)
>> ls(ea)
> [1] "fn" "ftrace" "gr" "ifn""igr"
>> ea$fn
> function(x) x^2 - 2*x + 1
>>
>> eb <- TraceSetup_2(fn = function(x
ario, Canada
> Web: https://socialsciences.mcmaster.ca/jfox/
>
>
>
>> -Original Message-
>> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>> Behalf Of J C Nash
>> Sent: Monday, August 27, 2018 8:44 PM
>> To:
TraceSetup -> -> registerNames
> Execution halted
Also had to use utils::globalVariables( ...
JN
On 2018-08-27 08:40 PM, Richard M. Heiberger wrote:
> Does this solve the problem?
>
> if (getRversion() >= '2.15.1')
> globalVariables(c('envroot'))
>
> I ke
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,
Will pending queries to CRAN-submissions about false positives in the check
process be cleared
first, or left pending? I've been waiting quite a while re: new optimx package,
which has 1 so-called "ERROR" (non-convergence, please use a different method
msg)
and 1 WARNING because new optimx
I think several of us have had similar issues lately. You might have seen my
posts on reverse dependencies.
It seems there are some sensitivities in the CRAN test setup, though I think
things are improving.
Last week I submitted optimx again. I don't think I changed anything but the
date and
Excuses for the length of this, but optimx has a lot of packages
using it.
Over the past couple of months, I have been struggling with checking
a new, and much augmented, optimx package. It offers some serious
improvements:
- parameter scaling on all methods
- two safeguarded Newton methods
For the past few weeks I've been struggling to check a new version of optimx
that gives
a major upgrade to the 2013 version currently on CRAN and subsumes several
other packages.
It seems to work fine, and pass Win-builder, R CMD check etc.
However, both devtools and cran reverse dependency
It occurs to me that there could be packages developed by early career R
developers that might fit
this prize which is considered quite prestigious (not to mention the cash) in
the numerical methods community.
It is also likely that people may not be aware of the award in the R community.
If NOTEs are going to be treated as errors, then a lot of infrastructure (all my
packages for optimization and nonlinear modelling, which are dependencies of
a few dozen other packages etc.) will disappear. This is because they have
version
numbering I've been using in some form that pre-dates R
> Georgi Boshnakov
>
>
>
>
>
> From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of J
> C Nash [profjcn...@gmail.com]
> Sent: 11 April 2018 19:05
> To: List r-package-devel
> Subject: [R-pkg-devel] Saving output of chec
esses. Output from these is not capturable/sinkable
> by the master R process. The gist of what's happening is:
>
>> sink("output.log")
>> system("echo hello") ## not sinked/captured
> hello
>> sink()
>> readLines("output.log")
&g
On 2018-04-11 03:24 PM, Henrik Bengtsson wrote:
> R CMD check, which is used internally runs checks in standalone
> background R processes. Output from these is not capturable/sinkable
> by the master R process. The gist of what's happening is:
>
>> sink("output.log")
&
'm running Linux Mint
18.3 Sylvia.
Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
john@john-j6-18 ~ $ R
R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
J C Nash
_
Duncan's observation is correct. The background work to the standards
I worked on was a big effort, and the content was a lot smaller than R,
though possibly similar in scope to dealing with the current question.
The "voting" was also very late in the process, after the proposals
were developed,
Having been around a while and part of several programming language and
other standards (see ISO 6373:1984 and IEEE 754-1985), I prefer some democracy
at the
level of getting a standard. Though perhaps at the design level I can agree
with Hadley. However, we're now at the stage of needing to
lig...@statistik.tu-dortmund.de> wrote:
On 15.03.2017 18:30, Ben Bolker wrote:
On 17-03-15 11:09 AM, J C Nash wrote:
Possibly tangential, but has there been any effort to set up a Sparc
testbed? It
seems we could use a network-available (virtual?) machine, since this
platform is
often the unfortuna
Possibly tangential, but has there been any effort to set up a Sparc testbed? It
seems we could use a network-available (virtual?) machine, since this platform
is
often the unfortunate one. Unless, of course, there's a sunset date.
For information, I mentioned SPARC at our local linux group,
advise others to do so. I
don't know how representative my little corner of the world is,
though.
I have an embryonic task view on mixed models at
https://github.com/bbolker/mixedmodels-misc/blob/master/MixedModels.ctv
but the perfect is the enemy of the good ...
On Fri, Feb 10, 2017 at 9:56 AM, J
We'd be more than happy to have you contribute directly. The goal is not just an
information session, but to get some movement to ways to make the package
collection(s)
easier to use effectively. Note to selves: "effectively" is important -- we
could make
things easy by only recommending a few
53 matches
Mail list logo