[Rd] SUGGESTION: Use JIRA for Bug Reporting, Package Development and Project Management

[TELLERIA RUIZ DE AGUIRRE, JUAN]

Dear R Developers,

I started programming in R just last January, for which I read (, summarized 
and memorized) 2 incredible R Programming books: "R Cookbook" and "R Graphics 
Cookbook".

However, I did before know how to program in MariaDB SQL language, and had 
submitted for their bug platform previously some bugs 
(https://jira.mariadb.org/projects/MDEV/issues), which is based on JIRA:

https://www.atlassian.com/software/jira

On the other hand, R has the mailing list, which is really simple, but:
a) I found it really difficult at first to understand how it worked.
b) I feel it does not fully respect the privacy of the package maintainers.
c) And it can give place to e-mail Spam.

In fact, Rstudio has disabled bug.report(package = "somePkg") command in order 
to avoid misuse.

That is why I would suggest that, being JIRA free for Open Source Projects such 
as R:

https://de.atlassian.com/software/views/open-source-license-request

It would be really worth it to start using this modern platform gradually 
instead of Bugzilla, or the mailing lists, for new R developed packages.

This would imply a considerable change to the R community, but I really think 
it would be worth it, and would help it to improve and be even greater. 
Although I might be wrong, and there might be different point of views which 
could be better than mine. However, I do sincerely think that testing this 
platform instead of Bugzilla would be really worth it.

Hope my suggestion is useful.

Kind regards,
Juan Telleria

[[alternative HTML version deleted]]

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

Re: [Rd] Usage of PROTECT_WITH_INDEX in R-exts

[Kirill Müller]

On 06.06.2017 22:14, Kirill Müller wrote:



On 06.06.2017 10:07, Martin Maechler wrote:

Kirill Müller 
 on Mon, 5 Jun 2017 17:30:20 +0200 writes:

 > Hi I've noted a minor inconsistency in the documentation:
 > Current R-exts reads

 > s = PROTECT_WITH_INDEX(eval(OS->R_fcall, OS->R_env), &ipx);

 > but I believe it has to be

 > PROTECT_WITH_INDEX(s = eval(OS->R_fcall, OS->R_env), &ipx);

 > because PROTECT_WITH_INDEX() returns void.

Yes indeed, thank you Kirill!

note that the same is true for its partner function|macro REPROTECT()

However, as  PROTECT() is used a gazillion times  and
PROTECT_WITH_INDEX() is used about 100 x less, and PROTECT()
*does* return the SEXP,
I do wonder why PROTECT_WITH_INDEX() and REPROTECT() could not
behave the same as PROTECT()
(a view at the source code seems to suggest a change to be trivial).
I assume usual compiler optimization would not create less
efficient code in case the idiom   PROTECT_WITH_INDEX(s = ...)
is used, i.e., in case the return value is not used ?

Maybe this is mainly a matter of taste,  but I find the use of

SEXP s = PROTECT();

quite nice in typical cases where this appears early in a function.
Also for that reason -- but even more for consistency -- it
would also be nice if  PROTECT_WITH_INDEX()  behaved the same.
Thanks, Martin, this sounds reasonable. I've put together a patch for 
review [1], a diff for applying to SVN (via `cat | patch -p1`) would 
be [2]. The code compiles on my system.



-Kirill


[1] https://github.com/krlmlr/r-source/pull/5/files

[2] 
https://patch-diff.githubusercontent.com/raw/krlmlr/r-source/pull/5.diff


I forgot to mention that this patch applies cleanly to r72768.


-Kirill






Martin

 > Best regards
 > Kirill


__
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] SUGGESTION: Use JIRA for Bug Reporting, Package Development and Project Management

[Sahil Kang]

I enjoy the simplicity of a mailing list; I'd prefer not to create a new user 
account to participate in a software project. Plenty of other software 
communities utilize mailing lists, and I think you'll also begin to prefer 
email as you get more involved with software projects.

R is also a GNU package​ so I don't think it's a good idea to use a closed 
source product like JIRA. I also think it's easier for the core devs to manage 
a mailing list instead of a JIRA instance.

I'm not sure what you mean about privacy concerns for package maintainers; can 
you elaborate?

Sahil

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

Re: [Rd] SUGGESTION: Use JIRA for Bug Reporting, Package Development and Project Management

[TELLERIA RUIZ DE AGUIRRE, JUAN]

#
## JIRA
#

# 
-
# - Advantages
# 
-

- It would allow the community (other than maintainers) to freely contribute 
giving suggestions to R patches on Packages, or R Base Code , boosting 
innovation.

- It does allow to attach documents, and sample files directly in the platform.

- Agile Project Management, open and in eyes of the community during the 
development.

# 
-
# - Disadvantages
# 
-

- That JIRA stops being Free at some time for Open Source Project (Maybe in 20 
years from now). So it would be critical to be able to ensure, by some sort of 
agreement, 
   that JIRA will be ALWAYS be free for R, as a life-long project.

- Need an account.

- ¿Complex?

#
## Mailing List & Bugzilla
#

# 
-
# - Privacy
# 
-

- What I mean with privacy concerns is that a developer has its e-mail exposed 
to the whole Internet, which might be what is desired, or not.

- ¿Spam?

# 
-
# - Advantages
# 
-

- Simplicity.

- Accessible.

# 
-
# - Disadvantages
# 
-

-  Easy to manage if you are part of few projects, but ¿Is it also easy to 
manage when you are part of a lot of projects? ¿And deliver all of them on 
time? 

-  Does not allow big file sharing, neither have them saved.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] SUGGESTION: Use JIRA for Bug Reporting, Package Development and Project Management

[Duncan Murdoch]

On 08/06/2017 6:31 AM, TELLERIA RUIZ DE AGUIRRE, JUAN wrote:

Dear R Developers,

I started programming in R just last January, for which I read (, summarized and memorized) 2 
incredible R Programming books: "R Cookbook" and "R Graphics Cookbook".

However, I did before know how to program in MariaDB SQL language, and had 
submitted for their bug platform previously some bugs 
(https://jira.mariadb.org/projects/MDEV/issues), which is based on JIRA:

https://www.atlassian.com/software/jira

On the other hand, R has the mailing list, which is really simple, but:
a) I found it really difficult at first to understand how it worked.
b) I feel it does not fully respect the privacy of the package maintainers.
c) And it can give place to e-mail Spam.

In fact, Rstudio has disabled bug.report(package = "somePkg") command in order 
to avoid misuse.

That is why I would suggest that, being JIRA free for Open Source Projects such 
as R:

https://de.atlassian.com/software/views/open-source-license-request

It would be really worth it to start using this modern platform gradually 
instead of Bugzilla, or the mailing lists, for new R developed packages.

This would imply a considerable change to the R community, but I really think 
it would be worth it, and would help it to improve and be even greater. 
Although I might be wrong, and there might be different point of views which 
could be better than mine. However, I do sincerely think that testing this 
platform instead of Bugzilla would be really worth it.

Hope my suggestion is useful.


You are talking about R and its packages as though they are all part of 
one project, but in fact most packages are separate projects.  Many of 
them use other systems for bug reporting and contributions.  Github is 
quite popular these days; many older packages use R-forge, and of course 
Bioconductor provides its own facilities.


I think it's unlikely that R itself would move to JIRA, for the reasons 
Sahil gave, and other reasons (including inertia).  But if you are 
arguing that individual packages should move to JIRA, you need to 
explain why it is better than Github, R-forge, Bioconductor, etc, not 
just better than the mailing lists.  I think it will be hard to make the 
argument, because all of those have R-specific features, as well as 
existing communities to go to for help.


Duncan Murdoch

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

Re: [Rd] SUGGESTION: Use JIRA for Bug Reporting, Package Development and Project Management

[TELLERIA RUIZ DE AGUIRRE, JUAN]

Thank you Duncan.

You really have a point. 

I made my suggestion based on a comparison between MariaDB Server (GNU GPL v2) 
Bug Reporting System (JIRA: https://jira.mariadb.org/projects/MDEV/issues & 
Github: https://github.com/MariaDB) and R (GNU GPL v2); and I thought "Base R" 
(Bugzilla / R-Devel) or "Packages" (Github, R-forge, Bioconductor, 
Mailing-List) could benefit from it, at it is a powerful resource in my opinion 
that community shall be aware off.

However, as it is right now it is also great.

Kind regards,
Juan

-Mensaje original-
De: Duncan Murdoch [mailto:murdoch.dun...@gmail.com] 
Enviado el: jueves, 08 de junio de 2017 16:52
Para: TELLERIA RUIZ DE AGUIRRE, JUAN; r-devel@r-project.org
Asunto: Re: [Rd] SUGGESTION: Use JIRA for Bug Reporting, Package Development 
and Project Management

On 08/06/2017 6:31 AM, TELLERIA RUIZ DE AGUIRRE, JUAN wrote:
> Dear R Developers,
>
> I started programming in R just last January, for which I read (, summarized 
> and memorized) 2 incredible R Programming books: "R Cookbook" and "R Graphics 
> Cookbook".
>
> However, I did before know how to program in MariaDB SQL language, and had 
> submitted for their bug platform previously some bugs 
> (https://jira.mariadb.org/projects/MDEV/issues), which is based on JIRA:
>
> https://www.atlassian.com/software/jira
>
> On the other hand, R has the mailing list, which is really simple, but:
> a) I found it really difficult at first to understand how it worked.
> b) I feel it does not fully respect the privacy of the package maintainers.
> c) And it can give place to e-mail Spam.
>
> In fact, Rstudio has disabled bug.report(package = "somePkg") command in 
> order to avoid misuse.
>
> That is why I would suggest that, being JIRA free for Open Source Projects 
> such as R:
>
> https://de.atlassian.com/software/views/open-source-license-request
>
> It would be really worth it to start using this modern platform gradually 
> instead of Bugzilla, or the mailing lists, for new R developed packages.
>
> This would imply a considerable change to the R community, but I really think 
> it would be worth it, and would help it to improve and be even greater. 
> Although I might be wrong, and there might be different point of views which 
> could be better than mine. However, I do sincerely think that testing this 
> platform instead of Bugzilla would be really worth it.
>
> Hope my suggestion is useful.

You are talking about R and its packages as though they are all part of one 
project, but in fact most packages are separate projects.  Many of them use 
other systems for bug reporting and contributions.  Github is quite popular 
these days; many older packages use R-forge, and of course Bioconductor 
provides its own facilities.

I think it's unlikely that R itself would move to JIRA, for the reasons Sahil 
gave, and other reasons (including inertia).  But if you are arguing that 
individual packages should move to JIRA, you need to explain why it is better 
than Github, R-forge, Bioconductor, etc, not just better than the mailing 
lists.  I think it will be hard to make the argument, because all of those have 
R-specific features, as well as existing communities to go to for help.

Duncan Murdoch

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

Re: [Rd] [bug] droplevels() also drop object attributes (comment…)

[Suharto Anggono Suharto Anggono via R-devel]

* Be careful with "contrasts" attribute. If the number of levels is reduced, 
the original contrasts matrix is no longer valid.
Example case:
x <- factor(c("a", "a", "b", "b", "b"), levels = c("a", "b", "c"))
contrasts(x) <- contr.treatment(levels(x), contrasts=FALSE)[, -2, drop=FALSE]
droplevels(x)

* If function 'factor' is changed, make sure that as.factor(x) and factor(x) is 
the same for 'x' where is.integer(x) is TRUE. Currently, as.factor() 
is treated specially.

* It is possible that names(x) is not attr(x, "names"). For example, 'x' is a 
"POSIXlt" object.
Look at this example, which works in R 3.3.2.
x <- as.POSIXlt("2017-01-01", tz="UTC")
factor(x, levels=x)


By the way, in NEWS, in "CHANGES IN R 3.4.0", in "SIGNIFICANT USER-VISIBLE 
CHANGES", there is "factor() now uses order() to sort its levels". It is false. 
Code of function 'factor' in R 3.4.0 
(https://svn.r-project.org/R/tags/R-3-4-0/src/library/base/R/factor.R) still 
uses 'sort.list', not 'order'.


> Martin Maechler 
> on Tue, 16 May 2017 11:01:23 +0200 writes:

> Serge Bibauw 
> on Mon, 15 May 2017 11:59:32 -0400 writes:

>> Hi,

>> Just reporting a small bug… not really a big deal, but I
>> don’t think that is intended: droplevels() also drops all
>> object’s attributes.

> Yes.  The help page for droplevels (or the simple
> definition of 'droplevels.factor') clearly indicate that
> the method for factors is really just a call to factor(x,
> exclude = *)

> and that _is_ quite an important base function whose
> semantic should not be changed lightly. Still, let's
> continue :

> Looking a bit, I see that the current behavior of factor()
> {and hence droplevels} has been unchanged in this respect
> for the whole history of R, well, at least for more than
> 17 years (R 1.0.1, April 2000).

> I'd agree there _is_ a bug, at least in the documentation
> which does *not* mention that currently, all attributes
> are dropped but "names", "levels" (and "class").

> OTOH, factor() would only need a small change to make it
> preserve all attributes (but "class" and "levels" which
> are set explicitly).

> I'm sure this will break some checks in some packages.  Is
> it worth it?

> e.g., our own R  QC checks currently check (the printing of) the
> following (in tests/reg-tests-2.R ):

>   > ## some tests of factor matrices
>   > A <- factor(7:12)
>   > dim(A) <- c(2, 3)
>   > A
>[,1] [,2] [,3]
>   [1,] 7911  
>   [2,] 810   12  
>   Levels: 7 8 9 10 11 12
>   > str(A)
>factor [1:2, 1:3] 7 8 9 10 ...
>- attr(*, "levels")= chr [1:6] "7" "8" "9" "10" ...
>   > A[, 1:2]
>[,1] [,2]
>   [1,] 79   
>   [2,] 810  
>   Levels: 7 8 9 10 11 12
>   > A[, 1:2, drop=TRUE]
>   [1] 7  8  9  10
>   Levels: 7 8 9 10
> 
> with the proposed change to factor(),
> the last call would change its result:
> 
>   > A[, 1:2, drop=TRUE]
>[,1] [,2]
>   [1,] 79   
>   [2,] 810  
>   Levels: 7 8 9 10

> because 'drop=TRUE' calls factor(..) and that would also
> preserve the "dim" attribute.  I would think that the
> changed behavior _is_ better, and is also according to
> documentation, because the help page for [.factor explains
> that 'drop = TRUE' drops levels, but _not_ that it
> transforms a factor matrix into a factor (vector).

> Martin

I'm finally coming back to this.
It still seems to make sense to change factor() and hence
droplevels() behavior here, and plan to commit this change
within a day.

Martin Maechler
ETH Zurich

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

[Rd] Creating a private CRAN with webpages

[Joshua Bradley]

Hello,

I am trying to setup a private CRAN for work (behind a firewall). The best
options available include miniCRAN
, drat
 and packrat
. One problem is these packages do not
automatically generate the web pages that are on the CRAN.

Examples:
https://cran.r-project.org/web/packages/index.html
https://cran.r-project.org/web/packages/available_packages_by_name.html

Each time the CRAN adds a package, there must be an automated process in
place to regenerate the pages again with the new package added (example - A3
). I read somewhere
(possibly on stackoverflow) that the CRAN html pages are statically built.
I would like for users to be able to explore the packages in my private
CRAN just like the public CRAN without having to open R and search for
packages/documentation through the command line.

The R Manual includes a small section

on setting up a repository but it only discusses the structure of the
directories needed to host packages. Nothing is mentioned about how the
CRAN creates/updates the /web directory. What is the best way to
generate/maintain the web pages for a private CRAN?

P.S. Let me know if this question is best answered on one of the other
mailing lists.

Josh Bradley

[[alternative HTML version deleted]]

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

Re: [Rd] Creating a private CRAN with webpages

[Rainer Krug]

If I understand you correctly, you want to have a mirror of CRAN on a private 
server behind your firewall. Check out 
https://cran.rstudio.com/mirror-howto.html 
 which gives instructions on how to 
do this.

Cheers,

Rainer

> On 8 Jun 2017, at 23:29, Joshua Bradley  wrote:
> 
> Hello,
> 
> I am trying to setup a private CRAN for work (behind a firewall). The best
> options available include miniCRAN
> , drat
>  and packrat
> . One problem is these packages do not
> automatically generate the web pages that are on the CRAN.
> 
> Examples:
> https://cran.r-project.org/web/packages/index.html
> https://cran.r-project.org/web/packages/available_packages_by_name.html
> 
> Each time the CRAN adds a package, there must be an automated process in
> place to regenerate the pages again with the new package added (example - A3
> ). I read somewhere
> (possibly on stackoverflow) that the CRAN html pages are statically built.
> I would like for users to be able to explore the packages in my private
> CRAN just like the public CRAN without having to open R and search for
> packages/documentation through the command line.
> 
> The R Manual includes a small section
> 
> on setting up a repository but it only discusses the structure of the
> directories needed to host packages. Nothing is mentioned about how the
> CRAN creates/updates the /web directory. What is the best way to
> generate/maintain the web pages for a private CRAN?
> 
> P.S. Let me know if this question is best answered on one of the other
> mailing lists.
> 
> Josh Bradley
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

University of Zürich

Cell:   +41 (0)78 630 66 57

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug



signature.asc
Description: Message signed with OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Creating a private CRAN with webpages

[Joshua Bradley]

I'm not trying to create a mirror of the CRAN. I also do not want to create
a "subset" of CRAN packages. Sorry if my explanation was confusing. There
are internal proprietary R packages that I would like to host on a private
repo. I like the CRAN web pages that allow a user to browse the various
packages from a browser without having to first install them. I want to
duplicate the process that CRAN goes through when it generate the webpages.

Josh Bradley

[[alternative HTML version deleted]]

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

Re: [Rd] Creating a private CRAN with webpages

[Martin Maechler]

> Rainer Krug 
> on Fri, 9 Jun 2017 08:36:31 +0200 writes:

> If I understand you correctly, you want to have a mirror
> of CRAN on a private server behind your firewall. Check
> out https://cran.rstudio.com/mirror-howto.html
>  which gives
> instructions on how to do this.  Cheers,

> Rainer

Yes, definitely:  Just use your private CRAN mirror... and instead
of the above URL, one with the same speed (and AFAIK still
sponsored by the same monney) is
  https://cloud.r-project.org/mirror-howto.html

There it tells you to use  rsync, and I strongly recommend you do!  

Martin Maechler,
ETH Zurich
(running one of the oldest - public - CRAN Mirrors)


>> On 8 Jun 2017, at 23:29, Joshua Bradley
>>  wrote:
>> 
>> Hello,
>> 
>> I am trying to setup a private CRAN for work (behind a
>> firewall). The best options available include miniCRAN
>> , drat
>>  and packrat
>> . One problem is
>> these packages do not automatically generate the web
>> pages that are on the CRAN.
>> 
>> Examples:
>> https://cran.r-project.org/web/packages/index.html
>> https://cran.r-project.org/web/packages/available_packages_by_name.html
>> 
>> Each time the CRAN adds a package, there must be an
>> automated process in place to regenerate the pages again
>> with the new package added (example - A3
>> ). I
>> read somewhere (possibly on stackoverflow) that the CRAN
>> html pages are statically built.  I would like for users
>> to be able to explore the packages in my private CRAN
>> just like the public CRAN without having to open R and
>> search for packages/documentation through the command
>> line.
>> 
>> The R Manual includes a small section
>> 

>> on setting up a repository but it only discusses the
>> structure of the directories needed to host
>> packages. Nothing is mentioned about how the CRAN
>> creates/updates the /web directory. What is the best way
>> to generate/maintain the web pages for a private CRAN?
>> 
>> P.S. Let me know if this question is best answered on one
>> of the other mailing lists.
>> 
>> Josh Bradley
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc
> (Conservation Biology, UCT), Dipl. Phys. (Germany)

> University of Zürich

> Cell: +41 (0)78 630 66 57

> Fax (D): +49 - (0)3 21 21 25 22 44

> email: rai...@krugs.de

> Skype: RMkrug

> xapplication/pgp-signature [Click mouse-2 to save to a
> file]

> --
> __
> 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