Programming Tools CTV

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Programming Tools CTV

Mxkuhn
I've had a lot of requests for additions to the reproducible research
task view that fall into a grey area (to me at least).

For example, roxygen2 is a tool that broadly enable reproducibility
but I see it more as a tool for better programming. I'm about to check
in a new version of the task view that includes packrat and
checkpoint, as they seem closer to reproducible research, but also
feel like coding tools.

There are a few other packages that many would find useful for better
coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
pkgutils, etc.

This might be some overlap with the HPC task view. I would think that
rJava, Rcpp and the like are better suited there but this is arguable.

The last time I proposed something like this, Martin deftly convinced
me to be the maintainer. It is probably better for everyone if we
avoid that on this occasion.

* Does anyone else see the need for this?

* What other packages fit into this bin?

* Would anyone like to volunteer?

Thanks,

Max

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Gregory R. Warnes-2
I second the motion for a Programming Tools CRAN Task View.

I would also think it could contain things like Rcpp, R6, etc.

-Greg


> On Jan 22, 2015, at 10:20 AM, Max Kuhn <[hidden email]> wrote:
>
> I've had a lot of requests for additions to the reproducible research
> task view that fall into a grey area (to me at least).
>
> For example, roxygen2 is a tool that broadly enable reproducibility
> but I see it more as a tool for better programming. I'm about to check
> in a new version of the task view that includes packrat and
> checkpoint, as they seem closer to reproducible research, but also
> feel like coding tools.
>
> There are a few other packages that many would find useful for better
> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
> pkgutils, etc.
>
> This might be some overlap with the HPC task view. I would think that
> rJava, Rcpp and the like are better suited there but this is arguable.
>
> The last time I proposed something like this, Martin deftly convinced
> me to be the maintainer. It is probably better for everyone if we
> avoid that on this occasion.
>
> * Does anyone else see the need for this?
>
> * What other packages fit into this bin?
>
> * Would anyone like to volunteer?
>
> Thanks,
>
> Max
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Henrik Bengtsson-3
In reply to this post by Mxkuhn
On Thu, Jan 22, 2015 at 7:20 AM, Max Kuhn <[hidden email]> wrote:

> I've had a lot of requests for additions to the reproducible research
> task view that fall into a grey area (to me at least).
>
> For example, roxygen2 is a tool that broadly enable reproducibility
> but I see it more as a tool for better programming. I'm about to check
> in a new version of the task view that includes packrat and
> checkpoint, as they seem closer to reproducible research, but also
> feel like coding tools.
>
> There are a few other packages that many would find useful for better
> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
> pkgutils, etc.
>
> This might be some overlap with the HPC task view. I would think that
> rJava, Rcpp and the like are better suited there but this is arguable.
>
> The last time I proposed something like this, Martin deftly convinced
> me to be the maintainer. It is probably better for everyone if we
> avoid that on this occasion.
>
> * Does anyone else see the need for this?
>
> * What other packages fit into this bin?
>
> * Would anyone like to volunteer?

Thanks for your work on this.

May I suggest a Git/GitHub repository for this?  That lowers the
barriers for contributions substantially, e.g. either via issues but
even better via pull requests (== point'n'click for you).  If you need
to mirror/push it to an SVN repository, I'm sure that's pretty easy to
do (and likely also to automate).

/Henrik

PS. Sorry, I'm not volunteering; too much on my plate.

>
> Thanks,
>
> Max
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Luca Braglia
In reply to this post by Gregory R. Warnes-2
Hi,

this summer, after few mails on this list, i started something similar
(feeling the same need)... here is the repo

https://github.com/lbraglia/PackageDevelopmentTaskView

Currently it's quite freezed since i'm working on other projects in my
free software spare time (and likely i won't return to it) but could
be a starting point for someone else interested.


Best, Luca

PS in the case, following some mails with Dirk and Achim, HPC stuff
a-la Rcpp and friends should not be copied from Dirk's stuff, better
pointing... it was in my mental TODO

2015-01-22 18:23 GMT+01:00 Gregory R. Warnes <[hidden email]>:

> I second the motion for a Programming Tools CRAN Task View.
>
> I would also think it could contain things like Rcpp, R6, etc.
>
> -Greg
>
>
>> On Jan 22, 2015, at 10:20 AM, Max Kuhn <[hidden email]> wrote:
>>
>> I've had a lot of requests for additions to the reproducible research
>> task view that fall into a grey area (to me at least).
>>
>> For example, roxygen2 is a tool that broadly enable reproducibility
>> but I see it more as a tool for better programming. I'm about to check
>> in a new version of the task view that includes packrat and
>> checkpoint, as they seem closer to reproducible research, but also
>> feel like coding tools.
>>
>> There are a few other packages that many would find useful for better
>> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
>> pkgutils, etc.
>>
>> This might be some overlap with the HPC task view. I would think that
>> rJava, Rcpp and the like are better suited there but this is arguable.
>>
>> The last time I proposed something like this, Martin deftly convinced
>> me to be the maintainer. It is probably better for everyone if we
>> avoid that on this occasion.
>>
>> * Does anyone else see the need for this?
>>
>> * What other packages fit into this bin?
>>
>> * Would anyone like to volunteer?
>>
>> Thanks,
>>
>> Max
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Achim Zeileis-4
In reply to this post by Mxkuhn
On Thu, 22 Jan 2015, Max Kuhn wrote:

> I've had a lot of requests for additions to the reproducible research
> task view that fall into a grey area (to me at least).
>
> For example, roxygen2 is a tool that broadly enable reproducibility
> but I see it more as a tool for better programming. I'm about to check
> in a new version of the task view that includes packrat and
> checkpoint, as they seem closer to reproducible research, but also
> feel like coding tools.
>
> There are a few other packages that many would find useful for better
> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
> pkgutils, etc.
>
> This might be some overlap with the HPC task view. I would think that
> rJava, Rcpp and the like are better suited there but this is arguable.
>
> The last time I proposed something like this, Martin deftly convinced
> me to be the maintainer. It is probably better for everyone if we
> avoid that on this occasion.
>
> * Does anyone else see the need for this?
>
> * What other packages fit into this bin?
>
> * Would anyone like to volunteer?

Max, thanks for the suggestion. We had a somewhat related proposal on
R-help from Luca Braglia a couple of months ago, suggesting a "Package
Development" task view:
https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html

He put up some ideas on Github:
https://github.com/lbraglia/PackageDevelopmentTaskView

When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer)
for feedback off-list, I replied that it is important that task views are
focused in order to be useful and maintainable. My feeling was that
"PackageDevelopment" was too broad and also "ProgrammingTools" is still
too board, I think. This could mean a lot of things/tools to a lot of
people.

But maybe it would be to factor out some aspect that is sharp and
clear(er)? Or split it up into bits where there are (more or less)
objectively clear criteria for what goes in and what does not?

Best,
Z

> Thanks,
>
> Max
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Mxkuhn
On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis
<[hidden email]> wrote:

> On Thu, 22 Jan 2015, Max Kuhn wrote:
>
>> I've had a lot of requests for additions to the reproducible research
>> task view that fall into a grey area (to me at least).
>>
>> For example, roxygen2 is a tool that broadly enable reproducibility
>> but I see it more as a tool for better programming. I'm about to check
>> in a new version of the task view that includes packrat and
>> checkpoint, as they seem closer to reproducible research, but also
>> feel like coding tools.
>>
>> There are a few other packages that many would find useful for better
>> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
>> pkgutils, etc.
>>
>> This might be some overlap with the HPC task view. I would think that
>> rJava, Rcpp and the like are better suited there but this is arguable.
>>
>> The last time I proposed something like this, Martin deftly convinced
>> me to be the maintainer. It is probably better for everyone if we
>> avoid that on this occasion.
>>
>> * Does anyone else see the need for this?
>>
>> * What other packages fit into this bin?
>>
>> * Would anyone like to volunteer?
>
>
> Max, thanks for the suggestion. We had a somewhat related proposal on R-help
> from Luca Braglia a couple of months ago, suggesting a "Package Development"
> task view:
> https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html
>
> He put up some ideas on Github:
> https://github.com/lbraglia/PackageDevelopmentTaskView
>
> When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer) for
> feedback off-list, I replied that it is important that task views are
> focused in order to be useful and maintainable. My feeling was that
> "PackageDevelopment" was too broad and also "ProgrammingTools" is still too
> board, I think. This could mean a lot of things/tools to a lot of people.
>
> But maybe it would be to factor out some aspect that is sharp and clear(er)?
> Or split it up into bits where there are (more or less) objectively clear
> criteria for what goes in and what does not?

It's funny that you said that. As I was updating the RR CTV, it
realized what a beast it is right now. I thought about making a github
project earlier today that would have more detailed examples and
information.

I see two problems with that as the *sole* solution.

First, it is divorced from CRAN CTV and that is a place that people
know and will look. I had no idea of Luca's work for this exact
reason.

Secondly, might be intimidating for new R users who, I think, are the
targeted cohort for the CTVs.

How about a relatively broad definition that is succinct in content
with a link to a github repos?

Thanks,

Max

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Achim Zeileis-4
On Thu, 22 Jan 2015, Max Kuhn wrote:

> On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis
> <[hidden email]> wrote:
>> On Thu, 22 Jan 2015, Max Kuhn wrote:
>>
>>> I've had a lot of requests for additions to the reproducible research
>>> task view that fall into a grey area (to me at least).
>>>
>>> For example, roxygen2 is a tool that broadly enable reproducibility
>>> but I see it more as a tool for better programming. I'm about to check
>>> in a new version of the task view that includes packrat and
>>> checkpoint, as they seem closer to reproducible research, but also
>>> feel like coding tools.
>>>
>>> There are a few other packages that many would find useful for better
>>> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
>>> pkgutils, etc.
>>>
>>> This might be some overlap with the HPC task view. I would think that
>>> rJava, Rcpp and the like are better suited there but this is arguable.
>>>
>>> The last time I proposed something like this, Martin deftly convinced
>>> me to be the maintainer. It is probably better for everyone if we
>>> avoid that on this occasion.
>>>
>>> * Does anyone else see the need for this?
>>>
>>> * What other packages fit into this bin?
>>>
>>> * Would anyone like to volunteer?
>>
>>
>> Max, thanks for the suggestion. We had a somewhat related proposal on R-help
>> from Luca Braglia a couple of months ago, suggesting a "Package Development"
>> task view:
>> https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html
>>
>> He put up some ideas on Github:
>> https://github.com/lbraglia/PackageDevelopmentTaskView
>>
>> When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer) for
>> feedback off-list, I replied that it is important that task views are
>> focused in order to be useful and maintainable. My feeling was that
>> "PackageDevelopment" was too broad and also "ProgrammingTools" is still too
>> board, I think. This could mean a lot of things/tools to a lot of people.
>>
>> But maybe it would be to factor out some aspect that is sharp and clear(er)?
>> Or split it up into bits where there are (more or less) objectively clear
>> criteria for what goes in and what does not?
>
> It's funny that you said that. As I was updating the RR CTV, it
> realized what a beast it is right now. I thought about making a github
> project earlier today that would have more detailed examples and
> information.
>
> I see two problems with that as the *sole* solution.
>
> First, it is divorced from CRAN CTV and that is a place that people
> know and will look. I had no idea of Luca's work for this exact
> reason.
>
> Secondly, might be intimidating for new R users who, I think, are the
> targeted cohort for the CTVs.

Yes, I agree. There should (an) additional task view(s) on CRAN related to
this.

> How about a relatively broad definition that is succinct in content
> with a link to a github repos?

I think this doesn't fit well with the existing development model and
might require duplicating changes in the <packagelist> of the task view.
In order to be easily installable I need the <packagelist> in the task
view on CRAN and not just in the linked list on Github.

Therefore, I would suggest splitting up the topic into things that are
fairly sharp and clear. (Of course, it is impossible to avoid overlap
completely.) For example, one could add "LanguageInterfaces" or something
like that.

And the task views on CRAN can always include <links> to further
documentation on Github and elsewhere. Especially when it comes to package
development there are also clearly different preferences about what is
good style or the right tools (say Github vs. R-Forge, knitr vs. Sweave,
etc.)

> Thanks,
>
> Max
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Mxkuhn
On Thu, Jan 22, 2015 at 1:05 PM, Achim Zeileis <[hidden email]> wrote:

> On Thu, 22 Jan 2015, Max Kuhn wrote:
>
>> On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis
>> <[hidden email]> wrote:
>>>
>>> On Thu, 22 Jan 2015, Max Kuhn wrote:
>>>
>>>> I've had a lot of requests for additions to the reproducible research
>>>> task view that fall into a grey area (to me at least).
>>>>
>>>> For example, roxygen2 is a tool that broadly enable reproducibility
>>>> but I see it more as a tool for better programming. I'm about to check
>>>> in a new version of the task view that includes packrat and
>>>> checkpoint, as they seem closer to reproducible research, but also
>>>> feel like coding tools.
>>>>
>>>> There are a few other packages that many would find useful for better
>>>> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
>>>> pkgutils, etc.
>>>>
>>>> This might be some overlap with the HPC task view. I would think that
>>>> rJava, Rcpp and the like are better suited there but this is arguable.
>>>>
>>>> The last time I proposed something like this, Martin deftly convinced
>>>> me to be the maintainer. It is probably better for everyone if we
>>>> avoid that on this occasion.
>>>>
>>>> * Does anyone else see the need for this?
>>>>
>>>> * What other packages fit into this bin?
>>>>
>>>> * Would anyone like to volunteer?
>>>
>>>
>>>
>>> Max, thanks for the suggestion. We had a somewhat related proposal on
>>> R-help
>>> from Luca Braglia a couple of months ago, suggesting a "Package
>>> Development"
>>> task view:
>>> https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html
>>>
>>> He put up some ideas on Github:
>>> https://github.com/lbraglia/PackageDevelopmentTaskView
>>>
>>> When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer)
>>> for
>>> feedback off-list, I replied that it is important that task views are
>>> focused in order to be useful and maintainable. My feeling was that
>>> "PackageDevelopment" was too broad and also "ProgrammingTools" is still
>>> too
>>> board, I think. This could mean a lot of things/tools to a lot of people.
>>>
>>> But maybe it would be to factor out some aspect that is sharp and
>>> clear(er)?
>>> Or split it up into bits where there are (more or less) objectively clear
>>> criteria for what goes in and what does not?
>>
>>
>> It's funny that you said that. As I was updating the RR CTV, it
>> realized what a beast it is right now. I thought about making a github
>> project earlier today that would have more detailed examples and
>> information.
>>
>> I see two problems with that as the *sole* solution.
>>
>> First, it is divorced from CRAN CTV and that is a place that people
>> know and will look. I had no idea of Luca's work for this exact
>> reason.
>>
>> Secondly, might be intimidating for new R users who, I think, are the
>> targeted cohort for the CTVs.
>
>
> Yes, I agree. There should (an) additional task view(s) on CRAN related to
> this.
>
>> How about a relatively broad definition that is succinct in content
>> with a link to a github repos?
>
>
> I think this doesn't fit well with the existing development model and might
> require duplicating changes in the <packagelist> of the task view. In order
> to be easily installable I need the <packagelist> in the task view on CRAN
> and not just in the linked list on Github.

Many of the task views are encyclopedic and still focused. Perhaps my
issues with RR are more related to how I currently organize it. I'll
try to solve it that way.

> Therefore, I would suggest splitting up the topic into things that are
> fairly sharp and clear. (Of course, it is impossible to avoid overlap
> completely.) For example, one could add "LanguageInterfaces" or something
> like that.

Looking at Luca's page, I think he does a great job of clustering
packages. My suggestions for focused topics are:

- Package Development*
- Foreign Languages Interfaces
- Code Analysis and Debugging
- Profiling and Benchmarking
- Unit Testing

* I would define the first one to be more narrow than the original definition.

I think that most of these would encompass less than 10 packages if we
don't include all the Rcpp depends =]

> And the task views on CRAN can always include <links> to further
> documentation on Github and elsewhere. Especially when it comes to package
> development there are also clearly different preferences about what is good
> style or the right tools (say Github vs. R-Forge, knitr vs. Sweave, etc.)

Yes. The comments above would not exclude this approach, which
is/was/might be my intention for RR.

Thanks,

Max

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Achim Zeileis-4
On Thu, 22 Jan 2015, Max Kuhn wrote:

> On Thu, Jan 22, 2015 at 1:05 PM, Achim Zeileis <[hidden email]> wrote:
>> On Thu, 22 Jan 2015, Max Kuhn wrote:
>>
>>> On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis
>>> <[hidden email]> wrote:
>>>>
>>>> On Thu, 22 Jan 2015, Max Kuhn wrote:
>>>>
>>>>> I've had a lot of requests for additions to the reproducible research
>>>>> task view that fall into a grey area (to me at least).
>>>>>
>>>>> For example, roxygen2 is a tool that broadly enable reproducibility
>>>>> but I see it more as a tool for better programming. I'm about to check
>>>>> in a new version of the task view that includes packrat and
>>>>> checkpoint, as they seem closer to reproducible research, but also
>>>>> feel like coding tools.
>>>>>
>>>>> There are a few other packages that many would find useful for better
>>>>> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
>>>>> pkgutils, etc.
>>>>>
>>>>> This might be some overlap with the HPC task view. I would think that
>>>>> rJava, Rcpp and the like are better suited there but this is arguable.
>>>>>
>>>>> The last time I proposed something like this, Martin deftly convinced
>>>>> me to be the maintainer. It is probably better for everyone if we
>>>>> avoid that on this occasion.
>>>>>
>>>>> * Does anyone else see the need for this?
>>>>>
>>>>> * What other packages fit into this bin?
>>>>>
>>>>> * Would anyone like to volunteer?
>>>>
>>>>
>>>>
>>>> Max, thanks for the suggestion. We had a somewhat related proposal on
>>>> R-help
>>>> from Luca Braglia a couple of months ago, suggesting a "Package
>>>> Development"
>>>> task view:
>>>> https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html
>>>>
>>>> He put up some ideas on Github:
>>>> https://github.com/lbraglia/PackageDevelopmentTaskView
>>>>
>>>> When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer)
>>>> for
>>>> feedback off-list, I replied that it is important that task views are
>>>> focused in order to be useful and maintainable. My feeling was that
>>>> "PackageDevelopment" was too broad and also "ProgrammingTools" is still
>>>> too
>>>> board, I think. This could mean a lot of things/tools to a lot of people.
>>>>
>>>> But maybe it would be to factor out some aspect that is sharp and
>>>> clear(er)?
>>>> Or split it up into bits where there are (more or less) objectively clear
>>>> criteria for what goes in and what does not?
>>>
>>>
>>> It's funny that you said that. As I was updating the RR CTV, it
>>> realized what a beast it is right now. I thought about making a github
>>> project earlier today that would have more detailed examples and
>>> information.
>>>
>>> I see two problems with that as the *sole* solution.
>>>
>>> First, it is divorced from CRAN CTV and that is a place that people
>>> know and will look. I had no idea of Luca's work for this exact
>>> reason.
>>>
>>> Secondly, might be intimidating for new R users who, I think, are the
>>> targeted cohort for the CTVs.
>>
>>
>> Yes, I agree. There should (an) additional task view(s) on CRAN related to
>> this.
>>
>>> How about a relatively broad definition that is succinct in content
>>> with a link to a github repos?
>>
>>
>> I think this doesn't fit well with the existing development model and might
>> require duplicating changes in the <packagelist> of the task view. In order
>> to be easily installable I need the <packagelist> in the task view on CRAN
>> and not just in the linked list on Github.
>
> Many of the task views are encyclopedic and still focused. Perhaps my
> issues with RR are more related to how I currently organize it. I'll
> try to solve it that way.
>
>> Therefore, I would suggest splitting up the topic into things that are
>> fairly sharp and clear. (Of course, it is impossible to avoid overlap
>> completely.) For example, one could add "LanguageInterfaces" or something
>> like that.
>
> Looking at Luca's page, I think he does a great job of clustering
> packages. My suggestions for focused topics are:
>
> - Package Development*
> - Foreign Languages Interfaces
> - Code Analysis and Debugging
> - Profiling and Benchmarking
> - Unit Testing

Yes, good suggestions. Now we only need willing maintainers :-)

> * I would define the first one to be more narrow than the original
> definition.

It's probably still the fuzziest one in the list above.

> I think that most of these would encompass less than 10 packages if we
> don't include all the Rcpp depends =]

:-)

>> And the task views on CRAN can always include <links> to further
>> documentation on Github and elsewhere. Especially when it comes to package
>> development there are also clearly different preferences about what is good
>> style or the right tools (say Github vs. R-Forge, knitr vs. Sweave, etc.)
>
> Yes. The comments above would not exclude this approach, which
> is/was/might be my intention for RR.

True.

thx,
Z

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Programming Tools CTV

Willem Ligtenberg
In reply to this post by Mxkuhn
Hi all,

Sorry if this doesn't end up in the thread.
Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV.
I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV.

It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated.
I myself am very interested in better/easier ways to develop faster and nicer code.

Kind regards,

Willem

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Luca Braglia
Hi Willem

thanks for volounteering.

To the best of my knowledge (regarding the machinery side), if you're
planning to use github (and maybe even if you don't) you can "stole"
ideas from

https://github.com/ropensci/webservices
https://github.com/lbraglia/PackageDevelopmentTaskView (minor
modifications from webservices)
https://github.com/eddelbuettel/ctv-finance or
https://github.com/eddelbuettel/ctv-hpc


HTH, Luca

2015-01-23 11:13 GMT+01:00 Willem Ligtenberg
<[hidden email]>:

> Hi all,
>
> Sorry if this doesn't end up in the thread.
> Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV.
> I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV.
>
> It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated.
> I myself am very interested in better/easier ways to develop faster and nicer code.
>
> Kind regards,
>
> Willem
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Luca Braglia
... BTW you should install the ctv package and read the vignette at
first :)  ...

2015-01-23 12:49 GMT+01:00 Luca Braglia <[hidden email]>:

> Hi Willem
>
> thanks for volounteering.
>
> To the best of my knowledge (regarding the machinery side), if you're
> planning to use github (and maybe even if you don't) you can "stole"
> ideas from
>
> https://github.com/ropensci/webservices
> https://github.com/lbraglia/PackageDevelopmentTaskView (minor
> modifications from webservices)
> https://github.com/eddelbuettel/ctv-finance or
> https://github.com/eddelbuettel/ctv-hpc
>
>
> HTH, Luca
>
> 2015-01-23 11:13 GMT+01:00 Willem Ligtenberg
> <[hidden email]>:
>> Hi all,
>>
>> Sorry if this doesn't end up in the thread.
>> Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV.
>> I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV.
>>
>> It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated.
>> I myself am very interested in better/easier ways to develop faster and nicer code.
>>
>> Kind regards,
>>
>> Willem
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Christophe Dutang1
In reply to this post by Luca Braglia
Dear Willem,

Personally, I use the R-forge project for the distribution CTV : https://r-forge.r-project.org/projects/ctv/

It’s an alternative option to github.

Regards, Christophe
---------------------------------------
Christophe Dutang
LMM, UdM, Le Mans, France
web: http://dutangc.free.fr

Le 23 janv. 2015 à 12:49, Luca Braglia <[hidden email]> a écrit :

> Hi Willem
>
> thanks for volounteering.
>
> To the best of my knowledge (regarding the machinery side), if you're
> planning to use github (and maybe even if you don't) you can "stole"
> ideas from
>
> https://github.com/ropensci/webservices
> https://github.com/lbraglia/PackageDevelopmentTaskView (minor
> modifications from webservices)
> https://github.com/eddelbuettel/ctv-finance or
> https://github.com/eddelbuettel/ctv-hpc
>
>
> HTH, Luca
>
> 2015-01-23 11:13 GMT+01:00 Willem Ligtenberg
> <[hidden email]>:
>> Hi all,
>>
>> Sorry if this doesn't end up in the thread.
>> Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV.
>> I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV.
>>
>> It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated.
>> I myself am very interested in better/easier ways to develop faster and nicer code.
>>
>> Kind regards,
>>
>> Willem
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Michael Dewey
Dear Willem

I maintain the MetaAnalysis CTV.

I have found it quite practicable to do this without special tools. I
use an editor for the XML. I use CRANberries to catch updates and I
usually email people to check I have understood a new package. People
also kindly email me occasionally with news about major changes.

On the other hand since it is the programming tools CTV I imagine you
will want to try out the latest all-singing, all-dancing technology. And
why not.

Michael

On 23/01/2015 13:05, Christophe Dutang wrote:

> Dear Willem,
>
> Personally, I use the R-forge project for the distribution CTV : https://r-forge.r-project.org/projects/ctv/
>
> It’s an alternative option to github.
>
> Regards, Christophe
> ---------------------------------------
> Christophe Dutang
> LMM, UdM, Le Mans, France
> web: http://dutangc.free.fr
>
> Le 23 janv. 2015 à 12:49, Luca Braglia <[hidden email]> a écrit :
>
>> Hi Willem
>>
>> thanks for volounteering.
>>
>> To the best of my knowledge (regarding the machinery side), if you're
>> planning to use github (and maybe even if you don't) you can "stole"
>> ideas from
>>
>> https://github.com/ropensci/webservices
>> https://github.com/lbraglia/PackageDevelopmentTaskView (minor
>> modifications from webservices)
>> https://github.com/eddelbuettel/ctv-finance or
>> https://github.com/eddelbuettel/ctv-hpc
>>
>>
>> HTH, Luca
>>
>> 2015-01-23 11:13 GMT+01:00 Willem Ligtenberg
>> <[hidden email]>:
>>> Hi all,
>>>
>>> Sorry if this doesn't end up in the thread.
>>> Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV.
>>> I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV.
>>>
>>> It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated.
>>> I myself am very interested in better/easier ways to develop faster and nicer code.
>>>
>>> Kind regards,
>>>
>>> Willem
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.5645 / Virus Database: 4260/8981 - Release Date: 01/23/15
>
>
>

--
Michael
http://www.dewey.myzen.co.uk

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

hadley wickham
In reply to this post by Luca Braglia
I'd strongly second the notion of using github. The biggest advantage
is that others can easily contribute changes through pull requests
which lifts much of the burden from your shoulders.

Hadley

On Fri, Jan 23, 2015 at 3:49 AM, Luca Braglia <[hidden email]> wrote:

> Hi Willem
>
> thanks for volounteering.
>
> To the best of my knowledge (regarding the machinery side), if you're
> planning to use github (and maybe even if you don't) you can "stole"
> ideas from
>
> https://github.com/ropensci/webservices
> https://github.com/lbraglia/PackageDevelopmentTaskView (minor
> modifications from webservices)
> https://github.com/eddelbuettel/ctv-finance or
> https://github.com/eddelbuettel/ctv-hpc
>
>
> HTH, Luca
>
> 2015-01-23 11:13 GMT+01:00 Willem Ligtenberg
> <[hidden email]>:
>> Hi all,
>>
>> Sorry if this doesn't end up in the thread.
>> Tobias Verbeke forwarded that e-mail to me, because he thought I would be interested in maintaining the Programming Tools CTV.
>> I wasn't subscribed to R-devel yet, but I would indeed like to volunteer to maintain the Programming Tools CTV.
>>
>> It will be my first time creating a CTV, so some guidance on getting it setup will be appreciated.
>> I myself am very interested in better/easier ways to develop faster and nicer code.
>>
>> Kind regards,
>>
>> Willem
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



--
http://had.co.nz/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Achim Zeileis-4
In reply to this post by Willem Ligtenberg
Willem,

thanks for volunteering!

> Sorry if this doesn't end up in the thread. Tobias Verbeke forwarded
> that e-mail to me, because he thought I would be interested in
> maintaining the Programming Tools CTV. I wasn't subscribed to R-devel
> yet, but I would indeed like to volunteer to maintain the Programming
> Tools CTV.

As discussed in the other thread: A programming tools task view would be
too broad and Max suggested splitting it up into sharper and more
manageable portions. Maybe you want to pick up one of these sub-topics?

> It will be my first time creating a CTV, so some guidance on getting it
> setup will be appreciated. I myself am very interested in better/easier
> ways to develop faster and nicer code.

The process is usually the following:

- Someone proposes to set up a certain task view - often here in the list
or in a direct e-mail to me.

- If the topic is deemed feasible for a task view, then the
maintainer-to-be compiles a .ctv file following the advice in
vignette("ctv", package = "ctv") and first sends it to me.

- If the maintainer-to-be and myself are satisfied with the result so far,
we typically try to get some more feedback from the mailing list and then
release it to CRAN.

As for version control:

The "ctv" package and all task view reside on R-Forge. All maintainers are
invited to join the R-Forge project and thus get access to the SVN
repository so that they can change their .ctv file directly. Most
maintainers do so but a few maintainers have chose to either use no
version control themselves or use some separate system (e.g., Github). In
the latter cases, updates are sent by e-mail to me.

Best,
Z

> Kind regards,
>
> Willem
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Programming Tools CTV

Dirk Eddelbuettel
In reply to this post by hadley wickham

On 23 January 2015 at 05:55, Hadley Wickham wrote:
| I'd strongly second the notion of using github. The biggest advantage
| is that others can easily contribute changes through pull requests
| which lifts much of the burden from your shoulders.

That's "The Theory".

"The Practice" for eight weeks having the High-Performance Computing and
Finance Task Views there (in "source" and a rendered markdown, see [1]) is a
single pull request fixing a one-char typo.

So the jury may still be out on that one.

Dirk

[1] As already shown in the email thread:
        https://github.com/eddelbuettel/ctv-hpc
        https://github.com/eddelbuettel/ctv-finance


--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel