On 31/01/2018 8:59 AM, Mark van der Loo wrote:
I fully agree with Joris and Hadley on roxygen2.
Additionally:
I wrote and published my first package before roxygen (or roxygen2) was
available. I found editing .Rd extremely terse (especially when code is
updated). For example, the fact that t
Thanks,
Uwe
On 31.01.2018 20:08, Simon Urbanek wrote:
Dirk,
yes, thanks, the edge server that serves the Mac binaries to CRAN has run out
of disk space (due to size of CRAN itself) so the sync was incomplete.
It is fixed now -- you can try by using the macos master server as mirror:
https://
The issue should be resolved in R-devel. It was actually deeper and more
important than this obscure insertSource() function. names() was not doing
the right thing on S4 objects derived from "environment".
On Mon, Jan 29, 2018 at 11:02 AM, Michael Lawrence
wrote:
> Thanks, I will fix this.
>
> O
Dirk,
yes, thanks, the edge server that serves the Mac binaries to CRAN has run out
of disk space (due to size of CRAN itself) so the sync was incomplete.
It is fixed now -- you can try by using the macos master server as mirror:
https://r.research.att.com/ and it will propagate through other mi
Bumping this as we now have two more issue tickets filed and a fresh SO
question.
Is anybody looking at this? Simon?
Dirk
On 30 January 2018 at 15:19, Dirk Eddelbuettel wrote:
|
| I have received three distinct (non-)bug reports where someone claimed a
| recent package of mine was broken ... s
Joris,
With the large caveat that I am not Duncan, and thus am not speaking for
him, I can see an argument for his claim that I think is, more or less,
true.
roxygen2 (as far as I know as someone who uses it at least some of the
time) maps to only a subset of Rd. It is the most commonly used subs
On 31 January 2018 at 16:18, Barry Rowlingson
wrote:
>>
>
> Let the record also state that *gitlab* is an open source project and can be
> downloaded and self-hosted, like gogs, but unlike github.
Good to know. Nice one: https://github.com/gitlabhq/gitlabhq
Best,
-m
> PS I've been running a g
Dear Dr. Pfaff,
Thank you for this, creating a package out of single file was my
oriingal question, but not only creating and also maintaining it that
way so R package is an artifact of the development process rather than
"manually maintained" structure. I will have look at your sources.
Best,
M
I pretty much agree. I tried using roxygen when it was first released but
couldn't stand putting documentation in comments, especially for complex,
S4-based software. Rd is easy to read and write and lets me focus on the
task of writing documentation (focus is the hardest part of any task for
me).
Similarly, I created this example a couple of years ago:
https://github.com/yihui/rlp which shows that you can create a package
from R Markdown documents (or any documents that knitr supports).
Basically you can start with an R Markdown document, and after
clicking a button in RStudio, you will get
On Tue, Jan 30, 2018 at 11:07 PM, Suzen, Mehmet
wrote:
> This might be off topic, but if R-core development ever moves to git,
> I think it would make sense to have its own git service hosted by a
> university, rather than using
> github or gitlab. It is possible via https://gogs.io/ project.
>
>
Dear All:
stepping in late, but @Joris, if you would like to take 'from a single file'
literally,
have a look at:
https://github.com/bpfaff/lp4rp
(lp4rp: literate programming for R packages);
Cheers,
Bernhard
ps: incidentally, within the noweb-file roxygen is employed.
-Ursprün
I fully agree with Joris and Hadley on roxygen2.
Additionally:
I wrote and published my first package before roxygen (or roxygen2) was
available. I found editing .Rd extremely terse (especially when code is
updated). For example, the fact that there are no spaces allowed between }
and { in \para
On Wed, Jan 31, 2018 at 1:41 PM, Duncan Murdoch
wrote:
> On 31/01/2018 6:33 AM, Joris Meys wrote:
>
> 3. given your criticism, I'd like your opinion on where I can improve the
>> documentation of https://github.com/CenterForStatistics-UGent/pim. I'm
>> currently busy updating the help files for a
(Please do not quote without attribution)
On 30 January 2018 at 20:44, Hadley Wickham wrote:
| Personally, I think the biggest problem with package.skeleton() is
| that it assumes that the source of truth is objects in an environment.
| This seems the wrong way around to me.
Basically irrelevant
On 31/01/2018 6:33 AM, Joris Meys wrote:
3. given your criticism, I'd like your opinion on where I can improve
the documentation of https://github.com/CenterForStatistics-UGent/pim.
I'm currently busy updating the help files for a next release on CRAN,
so your input is more than welcome.
Aft
On 31/01/2018 6:33 AM, Joris Meys wrote:
Dear Duncan,
With all respect, but I strongly disagree on your stance regarding
roxygen2 for multiple reasons:
1. It is in my humble opinion not correct to evaluate a tool based on
the abuse of some users. It's not because people write packages with b
On 30/01/2018 11:39 PM, Hadley Wickham wrote:
On Tue, Jan 30, 2018 at 4:55 PM, Duncan Murdoch
wrote:
On 30/01/2018 4:30 PM, Kenny Bell wrote:
In response to Duncan regarding the use of roxygen2 from the point of view
of a current user, I believe the issue he brings up is one of correlation
ra
Dear Duncan,
With all respect, but I strongly disagree on your stance regarding roxygen2
for multiple reasons:
1. It is in my humble opinion not correct to evaluate a tool based on the
abuse of some users. It's not because people write packages with bad
documentation, that roxygen2 is to blame. I
19 matches
Mail list logo
