[rkward-devel] R2HTML orphaned on CRAN
Thomas Friedrichsmeier
thomas.friedrichsmeier at ruhr-uni-bochum.de
Wed Aug 20 15:23:54 UTC 2014
Hi!
On Wednesday 20 August 2014 14:56:02 meik michalke wrote:
> Am Mittwoch, 20. August 2014, 13:57:06 schrieb Milan Bouchet-Valat:
> > If nobody steps in to take up
> >
> > maintainership, it will eventually be archived. As RKWard uses R2HTML
> > for output, it would be quite a bad situation.
>
> indeed.
>
> > Would you be interested in working at fixing the few R CMD check WARNINGs
> > and NOTEs in order to update the package?
>
> i sure don't have time to dig into the package to feel comfortable enough to
> make changes.
Well, yeah, we don't seem to be swimming in developer ressources, ATM.
> what are the options? evaluate which functionalitiy RKWard uses exactly, and
> try to replace R2HTML with maintained alternatives (if there is any)? two
> things come to my mind:
>
> print(xtable(), format="HTML")
>
> and extending XiMpLe to make generating HTML easy enough to become
> independent from other packages? here's some stuff i've been toying around
> for some other project:
That may not be the part that's actually difficult. BTW, we already create a
custom HTML header in the first place. See rk.set.output.html.file().
The really nice thing about R2HTML is that you can simply do
HTML (x)
(or rk.print (x)) and expect a reasonable result for most common classes of
objects. I do not think we actually use too many different classes in existing
plugins (some tables, lm-, and htest-objects, as far as I am aware), but so
far we can simply hint plugin authors to use rk.print(results) as a first, and
often sufficient way to present results.
Should R2HTML really go away, copying the bits we actually use, should not be
too hard. Alternatively, for most purposes,
rk.print.literal (capture.output (x))
or
rk.print.literal (capture.output (summary (results)))
would do the trick reasonably well. (And in fact, for some things, it may also
be preferrable).
One thing that could really mean trouble for us, is if R2HTML goes away,
before we are prepared for it. So I guess we need to decide (before 0.6.2),
whether
a) We rely on R2HTML to continue to be available on CRAN, because it's still
pretty popular, and somebody will certainly step forward.
b) We rely on R2HTML to continue to be available on CRAN, because we take care
of ensuring that ourselves.
c) We modify rk.print() to be functional without R2HTML, so disappearance of
R2HTML won't be catastrophic to RKWard.
Thoughts?
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20140820/58c111a3/attachment.sig>
More information about the Rkward-devel
mailing list