Re: [Rd] After package update, old S4 method is dispatched
Simon, Many thanks for your advice! The issue was that another package was inheriting from the "mirt" class in question. Apparently, some methods are cached at build time (is this documented anywhere?). After reinstalling the package that extends the "mirt" class, the proper method is now being dispatched. No other packages needed to be reinstalled. Best, Jan po 2. 10. 2023 v 20:56 odesílatel Simon Urbanek napsal: > Jan, > > have you re-installed all packages? If you change (update) any package > that uses S4 it may be necessary to re-install all its reverse-dependencies > as well since they may include cached values in their namespaces, so the > easiest is to make sure you re-install all packages. > > Cheers, > Simon > > > > On Oct 3, 2023, at 4:18 AM, Jan Netík wrote: > > > > Hello R-devel, > > > > I hope that you are all doing well and that this is the right place to > > discuss my somewhat mysterious issue with S4. > > > > On our Ubuntu server, we have "mirt" package installed which defines S4 > > method for "coef" standard generic. We updated the package with the usual > > "install.packages", restarted, and observer error calling coef on mirt > > object that should not be possible: "Error in which: argument "nfact" is > > missing, with no default" (which has no such argument). > > > > After days of investigation, I found that from mirt 1.37 to current 1.40, > > the method changed as well as some internal functions used by the method. > > The aforementioned error stems from the fact that these internal ordinary > > functions were changed properly as we updated the package, but the S4 > > method dispatched stuck with the 1.37 version. I am by no means an expert > > on S4 matter, but I know that these are cached to some extent. I thought > > the cache is session-bound and have no idea how the issue can possibly > > persist even after a complete reboot of the machine. I can detach and > > library() mirt in one R session which solves the issue temporarily, but > > emerges right back in any new R session. > > > > Sadly, I cannot provide any reproducible example as I am completely > unaware > > of the cause and even I cannot reproduce this issue outside of the > server. > > > > Any insights on how this issue could have started would be highly > > appreciated. > > > > Best regards, > > Jan Netík > > > > [[alternative HTML version deleted]] > > > > __ > > 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
[Rd] After package update, old S4 method is dispatched
Hello R-devel, I hope that you are all doing well and that this is the right place to discuss my somewhat mysterious issue with S4. On our Ubuntu server, we have "mirt" package installed which defines S4 method for "coef" standard generic. We updated the package with the usual "install.packages", restarted, and observer error calling coef on mirt object that should not be possible: "Error in which: argument "nfact" is missing, with no default" (which has no such argument). After days of investigation, I found that from mirt 1.37 to current 1.40, the method changed as well as some internal functions used by the method. The aforementioned error stems from the fact that these internal ordinary functions were changed properly as we updated the package, but the S4 method dispatched stuck with the 1.37 version. I am by no means an expert on S4 matter, but I know that these are cached to some extent. I thought the cache is session-bound and have no idea how the issue can possibly persist even after a complete reboot of the machine. I can detach and library() mirt in one R session which solves the issue temporarily, but emerges right back in any new R session. Sadly, I cannot provide any reproducible example as I am completely unaware of the cause and even I cannot reproduce this issue outside of the server. Any insights on how this issue could have started would be highly appreciated. Best regards, Jan Netík [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tools:: extracting pkg dependencies from DCF
Hello Jan, I have seen many packages that implemented dependencies "extraction" on their own for internal purposes and today I was doing exactly that for mine. It's not a big deal using read.dcf on DESCRIPTION. It was sufficient for me, but I had to take care of some \n chars (the overall returned value has some rough edges, in my opinion). However, the function from the branch seems to not care about version requirements, which are crucial for me. Maybe that is something to reconsider before merging. Best, Jan pá 14. 10. 2022 v 2:27 odesílatel Jan Gorecki napsal: > Dear R devs, > > I would like to raise a request for a simple helper function. > Utility function to extract package dependencies from DESCRIPTION file. > > I do think that tools package is better place, for such a fundamental > functionality, than community packages. > > tools pkg seems perfect fit (having already great function write_PACKAGES). > > Functionality I am asking for is already in R svn repository since 2016, in > a branch tools4pkgs. Function is called 'packages.dcf'. > Another one 'repos.dcf' would be a good functional complementary to it. > > Those two simple helper functions really makes it easier for organizations > to glue together usage of their own R packages repos and CRAN repo in a > smooth way. That could possibly help to offload CRAN from new submissions. > > gh mirror link for easy preview: > > https://github.com/wch/r-source/blob/tools4pkgs/src/library/tools/R/packages.R#L419 > > Regards > Jan Gorecki > > [[alternative HTML version deleted]] > > __ > 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] Bundling MathJax
Hello everyone,
glad to see the progress on this! It would be a major advancement in the
user experience of using our beloved _statistical_ language and
environment. I have brought the topic a year ago or so here and Simon
Urbanek offered a "hack" which I have implemented in the package many use
today (https://github.com/netique/documath). However, it is a customized
Rd2HTML injection, which is generally a really bad idea... (OT: check out
the {mvbutils} package, which I think does a bunch of "illegal" things,
such as rewriting base functions on the fly.)
As far as I know, I would certainly vote for KaTeX, as it is _perceivably_
faster and, as many of you mentioned, is capable of server-side rendering
which I deem promising.
Keep up the good work!
Best,
Jan
út 15. 3. 2022 v 11:44 odesílatel Viechtbauer, Wolfgang (SP) <
wolfgang.viechtba...@maastrichtuniversity.nl> napsal:
> Hi Ivan,
>
> I would say the biggest impact is in terms of the size of the installed
> package (~4MB versus ~2.9MB). Of course, these days this is a trivial
> difference in terms of storage. The decrease in load and execution time is
> probably negligible (esp. when MathJax is served locally), but I haven't
> done any proper benchmarks on this.
>
> Note that mathjaxr only minifies when the (suggested) 'js' package is
> installed, so this step is completely optional.
>
> Best,
> Wolfgang
>
> >-Original Message-
> >From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Ivan
> Krylov
> >Sent: Monday, 14 March, 2022 22:03
> >To: Duncan Murdoch
> >Cc: r-devel@r-project.org
> >Subject: Re: [Rd] Bundling MathJax
> >
> >On Sun, 13 Mar 2022 10:05:18 -0400
> >Duncan Murdoch wrote:
> >
> >> The file used for display is usually a minified version of the
> >> MathJax source, and Debian didn't consider it close enough to source
> >> code to want to distribute it as FOSS. So if the minified file is
> >> included with R, the original source should also be included.
> >
> >Pardon my ignorance, but how much does it matter whether the file is
> >minified when the documentation is served over a local network? Does
> >JavaScript minification speed up parsing or involve other
> >transformations without which it would be hard or impossible to run the
> >code in the browser?
> >
> >--
> >Best regards,
> >Ivan
>
> __
> 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] Feature request – math in HTML help
I am so sorry, my post sounded quite the opposite of what I intended! I
used the term "monkey patch" as a technical one (see
https://en.m.wikipedia.org/wiki/Monkey_patch) and I said "weird" meaning
mathjaxr is something fulfilling the concept, but only figuratively.
Actually I gave mathjaxr as a good (the best I know, in fact) example of an
approach how to solve the issue. However, no package can achieve nicely
formatted/rendered math in every single R documentation files. I thought
this could be solved globally, directly in R, as it is the case of PDF
Reference manual. I propose (in line with mathjaxr authors) that mathjax is
pretty good candidate for it.
Once more I am sorry for the ambiguity in my language.
Best,
Jan Netik
Dne čt 27. 5. 2021 22:15 uživatel Duncan Murdoch
napsal:
> On 27/05/2021 2:34 p.m., Jan Netík wrote:
> > Hi all,
> >
> > long I have been thinking about proper rendering of math in the HTML form
> > of R documentation. As you know, you can write \eqn{} in your .Rd files
> and
> > this is nicely rendered into the PDF Reference manual of the package with
> > the aid of TeX. However, that is not the case in the aforementioned HTML
> > version that is used the most in my experience (using RStudio or help
> > function in your console). I think R is the best language for
> statisticians
> > and other data-driven fields, where formal definitions of key concepts
> are
> > necessary and widely used in the documentation, unfortunately quite
> > unusable for more complicated equations.
> >
> > Recently I have stumbled upon an interesting approach to this issue, see
> > https://cran.r-project.org/package=mathjaxr, but it seems to me as some
> > weird kind of monkey patching. All packages should be able to benefit
> from
> > proper math rendering without any dependencies, in my opinion. I think it
> > should not be much of a problem utilizing mathjax or other similar
> library
> > to enable that. Note we already know what supposed to be math in .Rd (and
> > we parse and process it in a special way in the PDF routine), the thing
> is
> > to render it, not typeset in italics, as it is the case nowadays.
> >
> > I would be happy to hear any opinion of yours!
>
> You are being very rude.
>
> The problem has been solved by mathjaxr. If you don't like their
> approach, don't ask someone else (i.e. R Core) to come up with a
> different solution, do it yourself.
>
> I hope my opinion makes you happy!
>
> Duncan Murdoch
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Feature request – math in HTML help
Hi all,
long I have been thinking about proper rendering of math in the HTML form
of R documentation. As you know, you can write \eqn{} in your .Rd files and
this is nicely rendered into the PDF Reference manual of the package with
the aid of TeX. However, that is not the case in the aforementioned HTML
version that is used the most in my experience (using RStudio or help
function in your console). I think R is the best language for statisticians
and other data-driven fields, where formal definitions of key concepts are
necessary and widely used in the documentation, unfortunately quite
unusable for more complicated equations.
Recently I have stumbled upon an interesting approach to this issue, see
https://cran.r-project.org/package=mathjaxr, but it seems to me as some
weird kind of monkey patching. All packages should be able to benefit from
proper math rendering without any dependencies, in my opinion. I think it
should not be much of a problem utilizing mathjax or other similar library
to enable that. Note we already know what supposed to be math in .Rd (and
we parse and process it in a special way in the PDF routine), the thing is
to render it, not typeset in italics, as it is the case nowadays.
I would be happy to hear any opinion of yours!
Best,
Jan Netik
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
