[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