Re: [Rd] Programming Tools CTV

2015-01-22 Thread Luca Braglia
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 g...@warnes.net:
 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 mxk...@gmail.com 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

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] [Wishlist] a 'PackageDevelopment' Task View

2014-07-29 Thread Luca Braglia
On 27/07/14 -  13:19, Darren Norris wrote:
 including packages like sos seems justified and helpful.

Thanks Darren and John,

considering both the programmer and the user point of view, being
a bit less strict about inclusion criteria in this case (search)
may be definitely helpful.

Best, 
 Luca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] [Wishlist] a 'PackageDevelopment' Task View

2014-07-27 Thread Luca Braglia
On 27/07/14 -  09:33, Christophe Dutang wrote:
 Hi Luca,
 
 Let me suggest to follow the table of contents of 
 http://cran.r-project.org/doc/manuals/r-release/R-exts.html
 
 For example, you could use the following TOC:
 
 1 - Creating R pkg
 2 - Writing documentation and vignettes
 3 - Profiling code
 4 - Debugging, spell checking
 5 - Foreign languages interfaces
 6 - GUI and other frond-ends 
 7 - Unit testing
 8 - Benchmarking
 9 - Automation
 
 
 Maybe 7 and 8 could be merged?
 


Thanks Christophe for the feedback

I'm starting to think I'd like to keep the Source Code section
separated from the Documentation section ...  eg ideally the
macro topics could be in this order

1 - Creation
2 - Source Code
3 - Documentation
4 - Tools and services (was Automation)

Furthermore IMHO a granular sub-topic structure is a plus (eg
few packages for a distinct/well-focused task is no problem,
maybe a resource ... )

An updated temp TOC (integrating your ideas, and some new
packages listed) could be

==

1 - Creation


  o Creating R packages - utils::package.skeleton, pkgKitten,
Rcpp::Rcpp.package.skeleton 


2 - Source code


  o Foreign languages interfaces - base R support for that,
inline, Rcpp , Rcpp11, rJava 

  o Debugging - base::debug utils::recover and friends

  o Code analysis - codetools

  o Profiling - utils::Rprof, aprof, profr, proftools 

  o Benchmarking - base::system.time, microbenchmarking, rbenchmark 

  o Unit testing - RUnit, svUnit, testthat 


3 - Documentation


  o Writing Package Documentation (functions, data sets, classes
and methods, packages) - roxygen2

  o Writing Vignettes - Sweave, knitr

  o Spell checking - tools::aspell_package_* functions
   
 
4 - Tools and services


  o Editors (supporting package development)
  
  o IDEs (supporting package development)

  o Makefiles

  o Revision control (most common in the R community): 
subversion, git

  o Hosting services (most common in the R community): 
r-forge, github


==


I have a few doubts if 8.Linking GUIs and other front-ends to R
from R-exts could be strictly in topic with _R_package_
development (eg looking at the list above) but not much
experience in that area and jm2c.

And I have to integrate these Gabor's suggestions yet :

1) List the software mentioned here or provide links:
   
http://en.wikibooks.org/wiki/R_Programming/Settings#Integrated_development_environment
   
http://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities
   http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
   http://en.wikipedia.org/wiki/Continuous_integration#Software

2) Go through the R Extensions manual and add all tools listed.

3) Use of Rcpp/Rcpp11 implies the use of C++ tools too and use of
   rjava implies java tools.




Further ideas/comments/proposals are welcome.


Cheers, Luca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] [Wishlist] a 'PackageDevelopment' Task View

2014-07-27 Thread Luca Braglia
On 27/07/14 -  08:42, Spencer Graves wrote:
 On 7/27/2014 7:46 AM, Luca Braglia wrote:
 I'm starting to think I'd like to keep the Source Code section
 separated from the Documentation section ...  eg ideally the
 macro topics could be in this order
 
 1 - Creation
 2 - Source Code
 3 - Documentation
 4 - Tools and services (was Automation)
 
 Furthermore IMHO a granular sub-topic structure is a plus (eg
 few packages for a distinct/well-focused task is no problem,
 maybe a resource ... )
 
 An updated temp TOC (integrating your ideas, and some new
 packages listed) could be
 
 ==
 
 1 - Creation
 
 
o Creating R packages - utils::package.skeleton, pkgKitten,
  Rcpp::Rcpp.package.skeleton
 
 
 2 - Source code
 
 
o Foreign languages interfaces - base R support for that,
  inline, Rcpp , Rcpp11, rJava
 
o Debugging - base::debug utils::recover and friends
 
o Code analysis - codetools
 
o Profiling - utils::Rprof, aprof, profr, proftools
 
o Benchmarking - base::system.time, microbenchmarking, rbenchmark
 
o Unit testing - RUnit, svUnit, testthat
 
 
 3 - Documentation
 
 
o Writing Package Documentation (functions, data sets, classes
  and methods, packages) - roxygen2
 
o Writing Vignettes - Sweave, knitr
 
o Spell checking - tools::aspell_package_* functions
 4 - Tools and services
 
 
o Editors (supporting package development)
o IDEs (supporting package development)
 
o Makefiles
 
o Revision control (most common in the R community):
  subversion, git
 
o Hosting services (most common in the R community):
  r-forge, github
 
 
 ==
 
 
 
   I've heard claims that people who write documentation with unit tests
 first tend to get better code faster than people who write the code first
 and documentation (and maybe examples and unit tests) later.  I've heard
 there is research behind this.  However, I'm not sure where to find it.
 Others may be able to suggest publications that support or refute this
 claim.
 
 
   In any event, I tend to create (a) documentation first, including (b)
 unit tests in the examples section, before (c) writing code.  When I started
 writing R packages following this model, I felt my software development
 productivity increased by a factor of 5 or so.  


Hi Spencer,

I'm trying that way of developing too (test before code), but
the numbering in my previous mail are not meant to be suggestion
for development process/flow steps (apologies for that, it was
only a way to alternate lists (numbers for sections, bullets for
tasks), no numbering is really going to be included in the task
view).

The proposed TOC was compiled in a way that (to me) eases finding which
packages are available, given what are you working on (source code
or documentation) and the specific task you need to accomplish.

Best,
  Luca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] [Wishlist] a 'PackageDevelopment' Task View

2014-07-27 Thread Luca Braglia
On 27/07/14 -  10:07, Spencer Graves wrote:
   Regarding finding which packages are available, I didn't see the sos
 package on the list:  

Many packages are still missing (eg devtools) because in these
first steps i'm trying to focus mainly on the Task View TOC/structure
(and in the case, devtools has to be splitted across tasks, TODO)

BTW sos is a great package, +1 for the disclaimer, but IMHO
doesn't fit R package development strictly

jm2c
  Luca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] [Wishlist] a 'PackageDevelopment' Task View

2014-07-26 Thread Luca Braglia
2014-07-25 14:29 GMT+02:00 Duncan Murdoch murdoch.dun...@gmail.com:
 On 25/07/2014 8:05 AM, Luca Braglia wrote:

 Hello everybody,

 as a young/unexperienced R package developer (only a few, mainly
 for personal use) i was thinking it could be very useful having a
 meta task view for all package-development related
 packages and/or function.

 Something like ...

 Creation
 - utils::package.skeleton, pkgKitten, Rcpp::Rcpp.package.skeleton

 Foreign languages interfaces:
 - Rcpp

 Documentation
 - roxygen2

 Profiling:
 - utils::Rprof
 - profr
 - proftools

 Unit test
 - RUnit
 - testthat

 Spell checking
 - tools::aspell_package_* functions

 Misc:
 - devtools

 and so on.

 These are only the ones i (use or know)  (remember), but for
 sure there is already a lot of useful code in this area and
 having a summary (by more experienced developers) of which good
 tools are available would be *very* useful, IMHO.

 How about it?


 Sounds like a good idea.  You should do it.

 Download the ctv package, and read the vignette for instructions.

 Duncan Murdoch

Fine, I've set up a github repo here

https://github.com/lbraglia/PackageDevelopmentTaskView

and a first thread about task view structure here

https://github.com/lbraglia/PackageDevelopmentTaskView/issues/1

Contribution (via e-mail or github) are, of course, really welcome.

Cheers, Luca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] [Wishlist] a 'PackageDevelopment' Task View

2014-07-25 Thread Luca Braglia
Hello everybody,

as a young/unexperienced R package developer (only a few, mainly
for personal use) i was thinking it could be very useful having a
meta task view for all package-development related
packages and/or function.

Something like ...

Creation
- utils::package.skeleton, pkgKitten, Rcpp::Rcpp.package.skeleton

Foreign languages interfaces:
- Rcpp

Documentation
- roxygen2

Profiling:
- utils::Rprof
- profr
- proftools

Unit test
- RUnit
- testthat

Spell checking
- tools::aspell_package_* functions

Misc:
- devtools

and so on.

These are only the ones i (use or know)  (remember), but for
sure there is already a lot of useful code in this area and
having a summary (by more experienced developers) of which good
tools are available would be *very* useful, IMHO.

How about it?

Thanks, Luca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] error in the examples of a package

2014-05-28 Thread Luca Braglia
Is addpoints exported?

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] [lbrag...@gmail.com: [wishlist] \href in Rd]

2010-02-02 Thread Luca Braglia
mmm maybe lost somewhere

cheers

- Forwarded message from Luca Braglia lbrag...@gmail.com -

Subject: [wishlist] \href in Rd
Date: Wed, 27 Jan 2010 16:40:54 +0100
From: Luca Braglia lbrag...@gmail.com
To: R Bug r-b...@r-project.org
User-Agent: Mutt/1.5.20 (2009-06-14)

Following this thread

https://stat.ethz.ch/pipermail/r-help/2010-January/225856.html

it would be nice having an implementation of the LaTeX \href for Rd
too.

Thanks in advance
   Luca
  



- End forwarded message -

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] typos

2009-05-16 Thread Luca Braglia
Hi

few typos i've found


?.C

Specifying 'ENCODING' overrrides any declared encodings (see
 'link{Encoding}')

\link{Encoding}



writing R extensions, pag 73 (pdf version), note 1, 

and we provided an emulation on Windows 2000): see ?dyn.oad
^  ^^
1  2 

cut ) and dyn.load



writing R extensions
5.2 Interface functions .C and .Fortran

For .C only you can specify an ENCODING argument 
^^^

now also for .Fortran ;)



R Installation and Administration
1.2 Getting patched and development versions

A patched version of the current release, `r-patched' and the current
^^

a comma after `r-patched'


---

I also would like to close bug/wishlist #9613 ... It was a
juvenile mistake!  :)


Thank you, 
   Luca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] typo in italian translation (PR#10367)

2007-10-24 Thread Luca Braglia
On 24/10/07 -  08:07, Thomas Lumley wrote:

 Thanks for reporting this, but please report it to the Italian translation 
 team.  R-core doesn't try to manage translation bugs because most of us 
 don't know most of the languages.

 Contact addressses for the translation teams are listed at
   http://developer.r-project.org/TranslationTeams.html


ok, next time I'll send it directly to prof. Stefano Iacus


thanks for the advice


Luca Braglia

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel