Re: [Rd] Unicode display problem with data frames under Windows

2015-05-26 Thread Richard Cotton 
On 25 May 2015 at 19:43, Duncan Murdoch  wrote:
>> http://stackoverflow.com/questions/17715956/why-do-some-unicode-characters-display-in-matrices-but-not-data-frames-in-r

> Yes, but it is a bug, just a hard one to fix.  It needs someone to dedicate
> a serious amount of time to deal with it.
>
> Since most of the people who tend to do that generally use systems in UTF-8
> locales where this isn't a problem, or don't use Windows, it is languishing.

Thanks for the link and the explanation of why the bug exists.

>> On May 25, 2015 9:39 AM, "Richard Cotton"  wrote:
>>
>> > Here's a data frame with some Unicode symbols (set intersection and
>> > union).
>> >
>> > d <- data.frame(x = "A \u222a B \u2229 C")
>> >
>> > Printing this data frame under R 3.2.0 patched (r68378) and Windows 7, I
>> > see
>> >
>> > d
>> > ##  x
>> > ## 1 A  B n C

For future readers searching for a solution to this, you can get
correct printing by setting the CTYPE part of the locale to
Chinese/Japanese/Korean.

Sys.setlocale("LC_CTYPE", "Chinese")
## [1] "Chinese (Simplified)_People's Republic of China.936"

d
##x
## 1 A ∪ B ∩ C

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

Re: [Rd] Unicode display problem with data frames under Windows

2015-05-26 Thread Peter Meissner 

Am .05.2015, 09:01 Uhr, schrieb Richard Cotton :


On 25 May 2015 at 19:43, Duncan Murdoch  wrote:

http://stackoverflow.com/questions/17715956/why-do-some-unicode-characters-display-in-matrices-but-not-data-frames-in-r


Yes, but it is a bug, just a hard one to fix.  It needs someone to  
dedicate

a serious amount of time to deal with it.

Since most of the people who tend to do that generally use systems in  
UTF-8
locales where this isn't a problem, or don't use Windows, it is  
languishing.


Thanks for the link and the explanation of why the bug exists.

On May 25, 2015 9:39 AM, "Richard Cotton"   
wrote:


> Here's a data frame with some Unicode symbols (set intersection and
> union).
>
> d <- data.frame(x = "A \u222a B \u2229 C")
>
> Printing this data frame under R 3.2.0 patched (r68378) and Windows  
7, I

> see
>
> d
> ##  x
> ## 1 A  B n C


For future readers searching for a solution to this, you can get
correct printing by setting the CTYPE part of the locale to
Chinese/Japanese/Korean.

Sys.setlocale("LC_CTYPE", "Chinese")
## [1] "Chinese (Simplified)_People's Republic of China.936"

d
##x
## 1 A ∪ B ∩ C




There is another workaround.

The problem with the character transformation on printing data frames  
stems from format() used within print.default(). Defining your own class  
and print function that does not use format() allows for correct printing  
in all locales.


Like this:


d <- data.frame(x = "A \u222a B \u2229 C")
d
##  x
## 1 A  B n C


class(d) <- c("unicode_df","data.frame")

# this is print.default from base R with only two lines modified, see #old#
print.unicode_df <- function (x, ..., digits = NULL, quote = FALSE, right  
= TRUE,

row.names = TRUE)
{
n <- length(row.names(x))
if (length(x) == 0L) {
cat(sprintf(ngettext(n, "data frame with 0 columns and %d row",
"data frame with 0 columns and %d rows", domain = "R-base"),
n), "\n", sep = "")
}
else if (n == 0L) {
print.default(names(x), quote = FALSE)
cat(gettext("<0 rows> (or 0-length row.names)\n"))
}
else {
#old# m <- as.matrix(format.data.frame(x, digits = digits,
#old# na.encode = FALSE))
m <- as.matrix(x)
if (!isTRUE(row.names))
dimnames(m)[[1L]] <- if (identical(row.names, FALSE))
rep.int("", n)
else row.names
print(m, ..., quote = quote, right = right)
}
invisible(x)
}


d
##  x
## [1,] A ∪ B ∩ C




--
Erstellt mit Operas E-Mail-Modul: http://www.opera.com/mail/

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gábor Csárdi 
On Mon, May 25, 2015 at 8:28 PM, Simon Urbanek 
wrote:

> One issue I have with this is that it doesn't point to the original GitHub
> repositories of the packages, so you end up with additional repositories on
> Github in Gabor's name that have nothing to do with the actual Github
> repositories of the packages. I understand that it's technically necessary,
> but I fear it will lead to a lot of confusion...


Well, we point to the original GitHub repo is that is given in the URL
field. It would be nice to have an "official" field for source code
repository in DESCRIPTION.

But I agree with you that this has great potential for confusion. Several
people have been sending pull requests to github.com/cran repos, most of
them not realizing that they are not the right repos to fork. (Although
many packages are not on GH or any other similar service, and then are kind
of the places to fork.)

I could have a large warning popup on the link from r-pkg.org, with red
flags, and you would see this before the actual repo. But this has its own
problems, like being annoying after a while, how to turn it off with
browser cookies, etc.

The best would be to somehow have a warning on the GitHub repo pages, but
there isn't a lot I can modify there if I don't want to change/add the
README file, which would effectively change the package. I could probably
add 'WARNING: this is a read-only mirror, and not the original package
repository' to the one-line description on the top.

If you have other ideas, please let me know.

Gabor


> On May 24, 2015, at 5:44 AM, Rainer M Krug  wrote:
>
> > Gábor Csárdi  writes:
> >
> >> Dear All,
> >>
> >> [ I was wondering if this should have gone to the new mailing list.
> Maybe. ]
> >>
> >> As some of you maybe know from my earlier posts, I am building a simple
> >> search engine for R packages. Now the search engine has a proper web
> site,
> >> where you can also browse CRAN packages.
> >>
> >> http://www.r-pkg.org/
> >>
> >> As I see the value is in
> >> 1. package search (search box on top right)
> >> 2. APIs, see http://www.r-pkg.org/services
> >>
> >> It is in alpha version, meaning that things seem to work, some pages
> are a
> >> bit slow and there are a lot of glitches to fix.
> >
> > I had a quick peek, and it looks really nice! I particularly think the
> > github integration for diff-ing versions can be very use full!
> >
> > It might be an idea, to also add R itself to the github repo for
> > diff-ing?
> >
> > Thanks a lot,
> >
> > Rainer
> >
> >>
> >> Please tell me what you think.
> >>
> >> Best,
> >> Gabor
> >>
> >>  [[alternative HTML version deleted]]
> >>
> >
> > --
> > Rainer M. Krug
> > email: Rainerkrugsde
> > PGP: 0x0F52F982
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

[[alternative HTML version deleted]]

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

[Rd] Compatibility issue between lme4 and kml (operateur "[")

2015-05-26 Thread cgenolin 
Hi all,

There is a compatibility issue between the package 'lme4' and my package
'kml'. I define the "[" operator. It works just fine in my package (1). If I
try to use the lme4 package, then it does no longer work (2). Moreover, it
has some kind of strange behavior (3). Do you know what is wrong? Any idea
of how I can correct that?

Thanks for your help
Christophe

--- 8< - Code for reproductible example ---
library(kml)
dn <- gald(1)
dn["traj"]
library(lme4)
dn["traj"]
setMethod(   ### Simplified version ###
  "[",
  signature=signature(x="ClusterLongData", i="character",
j="ANY",drop="ANY"),
  definition=function (x, i, j="missing", ..., drop = TRUE){
  x <- as(x, "LongData")
  return(x[i, j])
}
)
dn["traj"]
dn["traj"]

--- 8< - Execution of the previous code ---

> library(kml)
Le chargement a nécessité le package : clv
Le chargement a nécessité le package : cluster
Le chargement a nécessité le package : class
Le chargement a nécessité le package : longitudinalData
Le chargement a nécessité le package : rgl
Le chargement a nécessité le package : misc3d
> dn <- gald(1)

  ###
  (1] 
### (1) the "[" operator works just fine

> dn["traj"]
  t0   t1t2t3t4   t5   t6t7t8t9   t10
i1 -3.11 4.32  2.17  1.82  4.90 7.34 0.83 -2.70  5.36  4.96  3.16
i2 -7.11 1.40 -2.40 -2.96  4.31 0.50 1.25  0.52 -0.04  7.55  5.50
i3  2.80 6.23  6.08  2.87  2.58 2.88 6.58 -2.38  2.30 -1.74 -3.23
i4  2.24 0.91  6.50 10.92 11.32 7.79 7.78 10.69  9.15  1.07 -0.51

  ###
  (2) 
### using 'lme4', it does no longer work

> library(lme4)
Le chargement a nécessité le package : Matrix
Le chargement a nécessité le package : Rcpp
> dn["traj"]
Error in x[i, j] : 
  erreur d'évaluation de l'argument 'j' lors de la sélection d'une méthode
pour la fonction '[' : Erreur : l'argument "j" est manquant, avec aucune
valeur par défaut

  ###
  (3) 
### If I define again the "[", it does not work the first time I call it,
but it work the second time!
> setMethod(
+   "[",
+   signature=signature(x="ClusterLongData", i="character",
j="ANY",drop="ANY"),
+   definition=function (x, i, j="missing", ..., drop = TRUE){
+   x <- as(x, "LongData")
+   return(x[i, j])
+ }
+ )
[1] "["

### No working the first time I use it
> dn["traj"]
Error in dn["traj"] : 
  l'argument "j" est manquant, avec aucune valeur par défaut

### But working the second time
> dn["traj"]
  t0   t1t2t3t4   t5   t6t7t8t9   t10
i1 -3.11 4.32  2.17  1.82  4.90 7.34 0.83 -2.70  5.36  4.96  3.16
i2 -7.11 1.40 -2.40 -2.96  4.31 0.50 1.25  0.52 -0.04  7.55  5.50
i3  2.80 6.23  6.08  2.87  2.58 2.88 6.58 -2.38  2.30 -1.74 -3.23
i4  2.24 0.91  6.50 10.92 11.32 7.79 7.78 10.69  9.15  1.07 -0.51






--
View this message in context: 
http://r.789695.n4.nabble.com/Compatibility-issue-between-lme4-and-kml-operateur-tp4707670.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] building with tcltk on Ubuntu 14.04

2015-05-26 Thread Ben Bolker 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  I'm having some issues trying to compile R-devel on Ubuntu 14.04.
library("tcltk") works fine on the version of R as installed from
Debian packages; I've done "apt-get build-dep r-base" so I think I
have all the tcltk libraries I need installed ... (and going back to
things like apt-get tcl-dev and apt-get tk-dev confirms that they're
really there ...)

  When I configure and build R without doing anything special, tcltk
is not found and capabilities()["tcltk"] is FALSE.  I modified
config.site as follows:

## Use TCLTK_LIBS for all '-L' and '-l' options needed for linking
TCLTK_LIBS="-L/usr/lib/x86_64-linux-gnu"
## Use TCLTK_CPPFLAGS for all '-I' options needed for finding the tcl.h
TCLTK_CPPFLAGS="-I/usr/include/tcl"

  This makes capabilities()["tcltk"] TRUE, but trying library("tcltk")
still returns

Error : .onLoad failed in loadNamespace() for 'tcltk', details:
  call: fun(libname, pkgname)
  error: Tcl/Tk support is not available on this system

  Any more suggestions on troubleshooting/diagnosing?  I'm not sure
what I should be telling R to look for ...

  thanks
Ben Bolker


PS  (I chose /usr/lib/x86_64-linux_gnu for TCLTK_LIBS because that's
where the tcl libraries seem to be located ...

ls /usr/lib/x86_64-linux-gnu/libtcl*
/usr/lib/x86_64-linux-gnu/libtcl8.5.a
/usr/lib/x86_64-linux-gnu/libtcl8.6.so
/usr/lib/x86_64-linux-gnu/libtclstub8.5.a
/usr/lib/x86_64-linux-gnu/libtcl8.5.so
/usr/lib/x86_64-linux-gnu/libtcl8.6.so.0
/usr/lib/x86_64-linux-gnu/libtclstub8.6.a
/usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
/usr/lib/x86_64-linux-gnu/libtcl.a
/usr/lib/x86_64-linux-gnu/libtclstub.a
/usr/lib/x86_64-linux-gnu/libtcl8.6.a
/usr/lib/x86_64-linux-gnu/libtcl.so
)


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJVZHxmAAoJEOCV5YRblxUHfe4IAL4RYDa89Hri91j7T//+RS+6
+/rnB6DH3QMVCYRtxmKFIZELhFyaU1pxe3/2p8gIWz8jIcVkGk3BEcdIeS0VgySk
wwrnfwv1PNE6gaun4CIWC/ICFQlCTAjo+eLFFYtSElETcm7UbRKMlojyWQSHjrf9
0ioloHZ72uajbzxcZdezRsYG/8+VwgkKWtoa5MfmggH5T8EL5QGD5S2aGqEPtWJe
UZUZCQFN43vRnHPgYxIQO3oXmjnnn0BsZlx+lXwqsRR7dplknCgQWyP0TEcv9Sur
GaemV2oEuUIpAgkMBZt2vTSGIrDgWUIfGcKT0nHNwtvh+cLcDuysj6M+6/JZCaQ=
=xkGy
-END PGP SIGNATURE-

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

Re: [Rd] building with tcltk on Ubuntu 14.04

2015-05-26 Thread Dirk Eddelbuettel 

Ben,

At work with little time so _real brief_:

 -- we build r-devel "all the time", in fact nightly for rocker; and there
are Dockerfiles to look at

 -- we build R all the time in Debian, Ubuntu, ... and my sources for that
are not on GH but you can fetch the diff.gz

 -- there is an entire list dedicated to this: r-sig-debian so could you
pretty-please post there (after registering, if needed)

I'll be glad to help, preferably on r-sig-debian.

Cheers, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] building with tcltk on Ubuntu 14.04

2015-05-26 Thread Ben Bolker 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  False alarm.  Completely wiping out my build directory followed by

../R-devel/configure --with-tcl-config=/usr/lib/tclConfig.sh
- --with-tk-config=/usr/lib/tkConfig.sh; make

  seems to work.  (My fault for assuming repeated cycles of
./configure; make would actually do the right thing ...)

  There seems to be a corollary of Clarke's Law ("any sufficient
advanced technology is indistinguishable from magic") that says that
any sufficiently complex software system may *not* be magic, but it's
just easier to treat it as though it is ...

  Thanks for the offer of help ...

  Ben


On 15-05-26 10:25 AM, Dirk Eddelbuettel wrote:
> 
> Ben,
> 
> At work with little time so _real brief_:
> 
> -- we build r-devel "all the time", in fact nightly for rocker; and
> there are Dockerfiles to look at
> 
> -- we build R all the time in Debian, Ubuntu, ... and my sources
> for that are not on GH but you can fetch the diff.gz
> 
> -- there is an entire list dedicated to this: r-sig-debian so could
> you pretty-please post there (after registering, if needed)
> 
> I'll be glad to help, preferably on r-sig-debian.
> 
> Cheers, Dirk
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJVZI2kAAoJEOCV5YRblxUHYEIH/j6jViruOP479yPNkRWXKNlA
0uXDYmZek/Zd2hwH6iHtmyTTLY3gR61metvLxFx/mpY3W/skM83Wpc9vWVHfUa8/
8aOaOndZnREEs5AT2TZwuYymXKYO7zEUeqL1cArXyzzqej0irUi5MjpWQsxD5hNA
M1LvpK3h31EWeJaJPdQHooZUMjgKKt1bJDrjIhs09J/jyVjUj5XANhsVfNUUbru5
pwXyMc3OMXfElgKM6/vO6gt1u2x7VHHpAZX7NrxgFksTaG4ceT0H8jUYIolCQmDy
RC7//onh0t8sqZCS3a4koZWy5mfnrcSc8M5PZaTZFnEQtU6D0jFSGCGGQ3Ncmow=
=UCFD
-END PGP SIGNATURE-

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Yihui Xie 
I cannot speak for other package authors, but for all my own packages,
I have provided the BugReports field in DESCRIPTION that points to the
Github issues page. You can probably use this field to check if a
package is on Github or not. If it is, you may just fork the original
repo instead of creating a new one from the CRAN package. I'm not sure
how technically difficult it would be for you. Thanks for the
wonderful work!

Regards,
Yihui
--
Yihui Xie 
Web: http://yihui.name


On Tue, May 26, 2015 at 2:45 AM, Gábor Csárdi  wrote:
> On Mon, May 25, 2015 at 8:28 PM, Simon Urbanek 
> wrote:
>
>> One issue I have with this is that it doesn't point to the original GitHub
>> repositories of the packages, so you end up with additional repositories on
>> Github in Gabor's name that have nothing to do with the actual Github
>> repositories of the packages. I understand that it's technically necessary,
>> but I fear it will lead to a lot of confusion...
>
>
> Well, we point to the original GitHub repo is that is given in the URL
> field. It would be nice to have an "official" field for source code
> repository in DESCRIPTION.
>
> But I agree with you that this has great potential for confusion. Several
> people have been sending pull requests to github.com/cran repos, most of
> them not realizing that they are not the right repos to fork. (Although
> many packages are not on GH or any other similar service, and then are kind
> of the places to fork.)
>
> I could have a large warning popup on the link from r-pkg.org, with red
> flags, and you would see this before the actual repo. But this has its own
> problems, like being annoying after a while, how to turn it off with
> browser cookies, etc.
>
> The best would be to somehow have a warning on the GitHub repo pages, but
> there isn't a lot I can modify there if I don't want to change/add the
> README file, which would effectively change the package. I could probably
> add 'WARNING: this is a read-only mirror, and not the original package
> repository' to the one-line description on the top.
>
> If you have other ideas, please let me know.
>
> Gabor

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gabriel Becker 
On Tue, May 26, 2015 at 9:25 AM, Yihui Xie  wrote:

> I cannot speak for other package authors, but for all my own packages,
> I have provided the BugReports field in DESCRIPTION that points to the
> Github issues page. You can probably use this field to check if a
> package is on Github or not. If it is, you may just fork the original
> repo instead of creating a new one from the CRAN package.


Maybe I'm missing something, but why would you fork the repo instead of
just using the existing repo?

-- 
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Hadley Wickham 
On Tue, May 26, 2015 at 12:18 PM, Gabriel Becker  wrote:
> On Tue, May 26, 2015 at 9:25 AM, Yihui Xie  wrote:
>
>> I cannot speak for other package authors, but for all my own packages,
>> I have provided the BugReports field in DESCRIPTION that points to the
>> Github issues page. You can probably use this field to check if a
>> package is on Github or not. If it is, you may just fork the original
>> repo instead of creating a new one from the CRAN package.
>
>
> Maybe I'm missing something, but why would you fork the repo instead of
> just using the existing repo?

One advantage of a fork is that you have permanent archive even if the
original goes away.

Hadley

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

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gábor Csárdi 
On Tue, May 26, 2015 at 1:26 PM, Hadley Wickham  wrote:

> > Maybe I'm missing something, but why would you fork the repo instead of
> > just using the existing repo?
>
> One advantage of a fork is that you have permanent archive even if the
> original goes away.
>

Exactly. Even if the original repo is on GitHub, I want to use one under
github.com/cran. Actually, I don't even want to fork the original repo,
because I want the github.com/cran repos to look the same: one commit per
package version, tagged with the version number. This way it is easy to
compare different versions of a package, easy to link to the code of a
specific version, etc.

If I link to the original repo, then I need the maintainer to tag releases
properly, etc. Many of them do, but still, I don't want to rely on that.

I obviously want to send potential contributors to the original upstream
repo, and I think I can do a better job at that, with warnings both on the
web page and in the github.com/cran repos. E.g. on the web page, we can
have a "Contribute" button, that goes upstream. On the cran GH page I can
have a warning line on top, with the link to the original repo.

Gabor

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gabriel Becker 
That's true, but issues, checkouts, comments, credit, etc should all be
going to the original repo. Anything else seems grossly unfair to the
package author(s). This issue is exacerbated even further when the the
author isn't developing the package on github at all, and github users may
unintentionally begin to view the forks as the actual canonical sources for
the package.

Also, the archive use-case, while near and dear to my own heart, seems
explicitly different from the "look at the package as it is now" use-case
that the forks are actually being used for.

To be clear, I think a lot of the metacran stuff is great. I use the APIs
myself and Gabor's work on this stuff is great.  I just think there are
some pitfalls here.

>From the email Gabor just sent out, it sounds like he and I agree about
this stuff anyway. I was really responding to the proposal that the
repositories actually be forked.

~G

On Tue, May 26, 2015 at 10:26 AM, Hadley Wickham 
wrote:

> On Tue, May 26, 2015 at 12:18 PM, Gabriel Becker 
> wrote:
> > On Tue, May 26, 2015 at 9:25 AM, Yihui Xie  wrote:
> >
> >> I cannot speak for other package authors, but for all my own packages,
> >> I have provided the BugReports field in DESCRIPTION that points to the
> >> Github issues page. You can probably use this field to check if a
> >> package is on Github or not. If it is, you may just fork the original
> >> repo instead of creating a new one from the CRAN package.
> >
> >
> > Maybe I'm missing something, but why would you fork the repo instead of
> > just using the existing repo?
>
> One advantage of a fork is that you have permanent archive even if the
> original goes away.
>
> Hadley
>
> --
> http://had.co.nz/
>



-- 
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gábor Csárdi 
On Tue, May 26, 2015 at 1:43 PM, Henrik Bengtsson  wrote:
[...]

> If people send pull requests, maybe adding a generic open pull request
> to each repository with title "MIRROR ONLY: Do not send pull requests
> here" would help.  The fancy version would be to say "MIRROR ONLY: All
> patches/pull requests should be sent to ", where  is from
> the DESCRIPTION field 'URL'.  That might prevent a few more.
>

The problem with that

1) if I put in ~7000 fake pull requests, then it is messy for me to find
the "real" pull requests, put in by other people, and
2) I am pretty sure that many people do not look at previous pull requests,
when they put in theirs.

But it is so far not such a big deal, I only got ~50 of them during ~12
months. And in many cases, they are useful, because they can be moved
upstream. I will write a short tutorial about that.

Gabor

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gábor Csárdi 
On Tue, May 26, 2015 at 1:46 PM, Gabriel Becker 
wrote:

> That's true, but issues, checkouts, comments, credit, etc should all be
> going to the original repo.


You mean the links? They are, aren't they?

[...]

> >From the email Gabor just sent out, it sounds like he and I agree about
> this stuff anyway. I was really responding to the proposal that the
> repositories actually be forked.
>

I cannot do much about that. Issues and wiki are turned off, but you cannot
turn off forking or pull requests. Even the official mirrors at GitHub have
them, e.g. the Apache Spark mirror at https://github.com/apache/spark

And I don't actually want to turn off forks for these repos, because they
are useful for repos that are originally not on CRAN.

Anyway, in summary I'll try to do a better job at directing people to the
original sources.

Gabor

[...]

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Henrik Bengtsson 
On Tue, May 26, 2015 at 12:45 AM, Gábor Csárdi  wrote:
> On Mon, May 25, 2015 at 8:28 PM, Simon Urbanek 
> wrote:
>
>> One issue I have with this is that it doesn't point to the original GitHub
>> repositories of the packages, so you end up with additional repositories on
>> Github in Gabor's name that have nothing to do with the actual Github
>> repositories of the packages. I understand that it's technically necessary,
>> but I fear it will lead to a lot of confusion...
>
>
> Well, we point to the original GitHub repo is that is given in the URL
> field. It would be nice to have an "official" field for source code
> repository in DESCRIPTION.
>
> But I agree with you that this has great potential for confusion. Several
> people have been sending pull requests to github.com/cran repos, most of
> them not realizing that they are not the right repos to fork. (Although
> many packages are not on GH or any other similar service, and then are kind
> of the places to fork.)
>
> I could have a large warning popup on the link from r-pkg.org, with red
> flags, and you would see this before the actual repo. But this has its own
> problems, like being annoying after a while, how to turn it off with
> browser cookies, etc.
>
> The best would be to somehow have a warning on the GitHub repo pages, but
> there isn't a lot I can modify there if I don't want to change/add the
> README file, which would effectively change the package. I could probably
> add 'WARNING: this is a read-only mirror, and not the original package
> repository' to the one-line description on the top.
>
> If you have other ideas, please let me know.

If people send pull requests, maybe adding a generic open pull request
to each repository with title "MIRROR ONLY: Do not send pull requests
here" would help.  The fancy version would be to say "MIRROR ONLY: All
patches/pull requests should be sent to ", where  is from
the DESCRIPTION field 'URL'.  That might prevent a few more.
You can boost it with lots of colorful "WARNING", "NO
TRESPASSING", ... labels as well.   The next level up is to
have a service that automatically reject pull requests with an
informative error message.

/Henrik


>
> Gabor
>
>
>> On May 24, 2015, at 5:44 AM, Rainer M Krug  wrote:
>>
>> > Gábor Csárdi  writes:
>> >
>> >> Dear All,
>> >>
>> >> [ I was wondering if this should have gone to the new mailing list.
>> Maybe. ]
>> >>
>> >> As some of you maybe know from my earlier posts, I am building a simple
>> >> search engine for R packages. Now the search engine has a proper web
>> site,
>> >> where you can also browse CRAN packages.
>> >>
>> >> http://www.r-pkg.org/
>> >>
>> >> As I see the value is in
>> >> 1. package search (search box on top right)
>> >> 2. APIs, see http://www.r-pkg.org/services
>> >>
>> >> It is in alpha version, meaning that things seem to work, some pages
>> are a
>> >> bit slow and there are a lot of glitches to fix.
>> >
>> > I had a quick peek, and it looks really nice! I particularly think the
>> > github integration for diff-ing versions can be very use full!
>> >
>> > It might be an idea, to also add R itself to the github repo for
>> > diff-ing?
>> >
>> > Thanks a lot,
>> >
>> > Rainer
>> >
>> >>
>> >> Please tell me what you think.
>> >>
>> >> Best,
>> >> Gabor
>> >>
>> >>  [[alternative HTML version deleted]]
>> >>
>> >
>> > --
>> > Rainer M. Krug
>> > email: Rainerkrugsde
>> > PGP: 0x0F52F982
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> [[alternative HTML version deleted]]
>
> __
> 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] MetaCran website v1.0.0-alpha

2015-05-26 Thread Dan Tenenbaum 


- Original Message -
> From: "Gábor Csárdi" 
> To: "Gabriel Becker" 
> Cc: "Simon Urbanek" , "Rainer M Krug" 
> , r-devel@r-project.org
> Sent: Tuesday, May 26, 2015 10:55:02 AM
> Subject: Re: [Rd] MetaCran website v1.0.0-alpha
> 
> On Tue, May 26, 2015 at 1:46 PM, Gabriel Becker
> 
> wrote:
> 
> > That's true, but issues, checkouts, comments, credit, etc should
> > all be
> > going to the original repo.
> 
> 
> You mean the links? They are, aren't they?
> 
> [...]
> 
> > >From the email Gabor just sent out, it sounds like he and I agree
> > >about
> > this stuff anyway. I was really responding to the proposal that the
> > repositories actually be forked.
> >
> 
> I cannot do much about that. Issues and wiki are turned off, but you
> cannot
> turn off forking or pull requests. 

No, but you can set up a 'bot' which listens for pull requests and then 
immediately denies them with a customizable message, perhaps giving people the 
url where they should be making their pull requests. Example:

https://github.com/bioconductor/prbot

Dan



> Even the official mirrors at
> GitHub have
> them, e.g. the Apache Spark mirror at https://github.com/apache/spark
> 
> And I don't actually want to turn off forks for these repos, because
> they
> are useful for repos that are originally not on CRAN.
> 
> Anyway, in summary I'll try to do a better job at directing people to
> the
> original sources.
> 
> Gabor
> 
> [...]
> 
>   [[alternative HTML version deleted]]
> 
> __
> 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] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gábor Csárdi 
On Tue, May 26, 2015 at 2:01 PM, Dan Tenenbaum 
wrote:
[...]

>
> No, but you can set up a 'bot' which listens for pull requests and then
> immediately denies them with a customizable message, perhaps giving people
> the url where they should be making their pull requests. Example:


> https://github.com/bioconductor/prbot


Yes, that's what I am doing, by hand currently. I closed all of them and
explained that this is not the right place for them. It's one PR per week
so far, and sometimes I need to interact with the people, so it is fine. If
it will be more, I'll use your robot, thanks!

Gabor



> Dan
>
>
>
> > Even the official mirrors at
> > GitHub have
> > them, e.g. the Apache Spark mirror at https://github.com/apache/spark
> >
> > And I don't actually want to turn off forks for these repos, because
> > they
> > are useful for repos that are originally not on CRAN.
> >
> > Anyway, in summary I'll try to do a better job at directing people to
> > the
> > original sources.
> >
> > Gabor
> >
> > [...]
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gabriel Becker 
On Tue, May 26, 2015 at 10:55 AM, Gábor Csárdi 
wrote:

> On Tue, May 26, 2015 at 1:46 PM, Gabriel Becker 
> wrote:
>
>> That's true, but issues, checkouts, comments, credit, etc should all be
>> going to the original repo.
>
>
> You mean the links? They are, aren't they?
>

Sort of, the link for browsing source code doesn't have any indication that
you're looking at a frozen snapshot of the source-code for the latest
version on CRAN. Typically links with that description point to trunk, I
think. Maybe a different a description for that link would help make the
source-code it points to sound less official?


>
> [...]
>
>> >From the email Gabor just sent out, it sounds like he and I agree about
>> this stuff anyway. I was really responding to the proposal that the
>> repositories actually be forked.
>>
>
> I cannot do much about that. Issues and wiki are turned off, but you
> cannot turn off forking or pull requests. Even the official mirrors at
> GitHub have them, e.g. the Apache Spark mirror at
> https://github.com/apache/spark
>
> And I don't actually want to turn off forks for these repos, because they
> are useful for repos that are originally not on CRAN.
>

Well, sort of. I mean if the package is being actively developed not on
github, forking your archive repo and developing a patch/etc against it
won't necessarily be particularly effective, as there is no way to have the
right starting point (state of trunk), right?


~G


-- 
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Gábor Csárdi 
On Tue, May 26, 2015 at 2:10 PM, Gabriel Becker 
wrote:
[...]

>
> Well, sort of. I mean if the package is being actively developed not on
> github, forking your archive repo and developing a patch/etc against it
> won't necessarily be particularly effective, as there is no way to have the
> right starting point (state of trunk), right?
>

Well, then you can do 1) git rebase or 2) get the patch if the original
repo is not in git.

Yes, this is not ideal. I could remove that "Browse the source" completely,
that is an option, and remove the link from the version number as well.
There there will be no links to github.com/cran. Experienced users will
just type in the URL. That's fine with me, too.

Btw. how does this look for a warning: https://github.com/cran/crayon
This is the most red I could find.

G.

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Tim Triche, Jr. 
Or maybe it would be sensible to ask GitHub if they can fix this.

If it's a common-ish use case (e.g. for mirrors), it's not something that
should be terribly challenging engineering-wise, and it would prevent a lot
of hooha.

Funfact: GitHub is run and staffed by actual people, most of them pretty
cool



Statistics is the grammar of science.
Karl Pearson 

On Tue, May 26, 2015 at 10:43 AM, Henrik Bengtsson <
henrik.bengts...@ucsf.edu> wrote:

> On Tue, May 26, 2015 at 12:45 AM, Gábor Csárdi 
> wrote:
> > On Mon, May 25, 2015 at 8:28 PM, Simon Urbanek <
> simon.urba...@r-project.org>
> > wrote:
> >
> >> One issue I have with this is that it doesn't point to the original
> GitHub
> >> repositories of the packages, so you end up with additional
> repositories on
> >> Github in Gabor's name that have nothing to do with the actual Github
> >> repositories of the packages. I understand that it's technically
> necessary,
> >> but I fear it will lead to a lot of confusion...
> >
> >
> > Well, we point to the original GitHub repo is that is given in the URL
> > field. It would be nice to have an "official" field for source code
> > repository in DESCRIPTION.
> >
> > But I agree with you that this has great potential for confusion. Several
> > people have been sending pull requests to github.com/cran repos, most of
> > them not realizing that they are not the right repos to fork. (Although
> > many packages are not on GH or any other similar service, and then are
> kind
> > of the places to fork.)
> >
> > I could have a large warning popup on the link from r-pkg.org, with red
> > flags, and you would see this before the actual repo. But this has its
> own
> > problems, like being annoying after a while, how to turn it off with
> > browser cookies, etc.
> >
> > The best would be to somehow have a warning on the GitHub repo pages, but
> > there isn't a lot I can modify there if I don't want to change/add the
> > README file, which would effectively change the package. I could probably
> > add 'WARNING: this is a read-only mirror, and not the original package
> > repository' to the one-line description on the top.
> >
> > If you have other ideas, please let me know.
>
> If people send pull requests, maybe adding a generic open pull request
> to each repository with title "MIRROR ONLY: Do not send pull requests
> here" would help.  The fancy version would be to say "MIRROR ONLY: All
> patches/pull requests should be sent to ", where  is from
> the DESCRIPTION field 'URL'.  That might prevent a few more.
> You can boost it with lots of colorful "WARNING", "NO
> TRESPASSING", ... labels as well.   The next level up is to
> have a service that automatically reject pull requests with an
> informative error message.
>
> /Henrik
>
>
> >
> > Gabor
> >
> >
> >> On May 24, 2015, at 5:44 AM, Rainer M Krug  wrote:
> >>
> >> > Gábor Csárdi  writes:
> >> >
> >> >> Dear All,
> >> >>
> >> >> [ I was wondering if this should have gone to the new mailing list.
> >> Maybe. ]
> >> >>
> >> >> As some of you maybe know from my earlier posts, I am building a
> simple
> >> >> search engine for R packages. Now the search engine has a proper web
> >> site,
> >> >> where you can also browse CRAN packages.
> >> >>
> >> >> http://www.r-pkg.org/
> >> >>
> >> >> As I see the value is in
> >> >> 1. package search (search box on top right)
> >> >> 2. APIs, see http://www.r-pkg.org/services
> >> >>
> >> >> It is in alpha version, meaning that things seem to work, some pages
> >> are a
> >> >> bit slow and there are a lot of glitches to fix.
> >> >
> >> > I had a quick peek, and it looks really nice! I particularly think the
> >> > github integration for diff-ing versions can be very use full!
> >> >
> >> > It might be an idea, to also add R itself to the github repo for
> >> > diff-ing?
> >> >
> >> > Thanks a lot,
> >> >
> >> > Rainer
> >> >
> >> >>
> >> >> Please tell me what you think.
> >> >>
> >> >> Best,
> >> >> Gabor
> >> >>
> >> >>  [[alternative HTML version deleted]]
> >> >>
> >> >
> >> > --
> >> > Rainer M. Krug
> >> > email: Rainerkrugsde
> >> > PGP: 0x0F52F982
> >> > __
> >> > R-devel@r-project.org mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Tim Triche, Jr. 
What you are doing is great, and that's a pretty clear warning (I would go
ahead and add "DO NOT FORK ME" to the verbiage since I am one of the
dumbasses who submitted a pull request in such a fashion, whereupon the
original author got to set up a Git repo, I re-PR'ed against that, and all
was well).  But the fact that Dan wrote a bot for the BioC git mirror
specifically to bounce PR's... well, it's unlikely that this is an isolated
need.

A simple switch indicating that a repo is a mirror and should not accept
pull requests would be something that GitHub could implement once, and an
entire class of users would benefit from it.  It might even be a selling
point for business users, people who pay for private repos, etc.

I am going to get in touch with a former coworker who now works at GitHub
and ask him how much trouble this would really be on their end.  It's so
easy to underestimate the scope of features from outside, but if it really
is as easy as adding a hook to bounce PRs, I hope they will consider it as
a use case.




Statistics is the grammar of science.
Karl Pearson 

On Tue, May 26, 2015 at 11:16 AM, Gábor Csárdi 
wrote:

> On Tue, May 26, 2015 at 2:10 PM, Gabriel Becker 
> wrote:
> [...]
>
> >
> > Well, sort of. I mean if the package is being actively developed not on
> > github, forking your archive repo and developing a patch/etc against it
> > won't necessarily be particularly effective, as there is no way to have
> the
> > right starting point (state of trunk), right?
> >
>
> Well, then you can do 1) git rebase or 2) get the patch if the original
> repo is not in git.
>
> Yes, this is not ideal. I could remove that "Browse the source" completely,
> that is an option, and remove the link from the version number as well.
> There there will be no links to github.com/cran. Experienced users will
> just type in the URL. That's fine with me, too.
>
> Btw. how does this look for a warning: https://github.com/cran/crayon
> This is the most red I could find.
>
> G.
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] MetaCran website v1.0.0-alpha

2015-05-26 Thread Henrik Bengtsson 
On Tue, May 26, 2015 at 10:46 AM, Gabriel Becker  wrote:
> That's true, but issues, checkouts, comments, credit, etc should all be
> going to the original repo. Anything else seems grossly unfair to the
> package author(s). This issue is exacerbated even further when the the
> author isn't developing the package on github at all, and github users may
> unintentionally begin to view the forks as the actual canonical sources for
> the package.

The same problem exists for CRAN (and for some of the Bioconductor
packages), i.e. the "source" tarballs (*.tar.gz files) on the
repository are often mistakenly seen as the main/root source of the
package.  The risk for this is less so when the package maintainer
share the source on a public version control system.  I think of CRAN
as an archive of specific package versions.  I look at Gabor's
MetaCRAN exactly the same way.  (I agree that the concept of a
"commit" may be confusing though, where it should really be a
"release").

/Henrik

>
> Also, the archive use-case, while near and dear to my own heart, seems
> explicitly different from the "look at the package as it is now" use-case
> that the forks are actually being used for.
>
> To be clear, I think a lot of the metacran stuff is great. I use the APIs
> myself and Gabor's work on this stuff is great.  I just think there are
> some pitfalls here.
>
> >From the email Gabor just sent out, it sounds like he and I agree about
> this stuff anyway. I was really responding to the proposal that the
> repositories actually be forked.
>
> ~G
>
> On Tue, May 26, 2015 at 10:26 AM, Hadley Wickham 
> wrote:
>
>> On Tue, May 26, 2015 at 12:18 PM, Gabriel Becker 
>> wrote:
>> > On Tue, May 26, 2015 at 9:25 AM, Yihui Xie  wrote:
>> >
>> >> I cannot speak for other package authors, but for all my own packages,
>> >> I have provided the BugReports field in DESCRIPTION that points to the
>> >> Github issues page. You can probably use this field to check if a
>> >> package is on Github or not. If it is, you may just fork the original
>> >> repo instead of creating a new one from the CRAN package.
>> >
>> >
>> > Maybe I'm missing something, but why would you fork the repo instead of
>> > just using the existing repo?
>>
>> One advantage of a fork is that you have permanent archive even if the
>> original goes away.
>>
>> Hadley
>>
>> --
>> http://had.co.nz/
>>
>
>
>
> --
> Gabriel Becker, PhD
> Computational Biologist
> Bioinformatics and Computational Biology
> Genentech, Inc.
>
> [[alternative HTML version deleted]]
>
> __
> 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