Re: [Rd] R-Forge > GitHub?

[Spencer Graves]

Hi, Henrik Singmann et al.:


   Thanks for the suggestions.  I tried again to pull 
"https://github.com/sbgraves237/Ecdat"; from R-Forge, with the same 
"Error 500" as before.  Then I tried pulling from 
"https://github.com/rforge/ecdat";, which seemed to work ... AND the copy 
I pulled was at the latest revisions I had posted to R-Forge (520), so 
that makes it easier going forward.


   What do you suggest I do next?  I'm thinking of the following:


         1.  Clone a copy of "https://github.com/sbgraves237/Ecdat"; 
to my local computer and confirm that it works.


         2.  Modify "https://r-forge.r-project.org/projects/ecdat/"; 
to make me the only remaining project member, if I can.


         3.  Contact GitHub support and ask them if they can delete 
"https://github.com/rforge/ecdat";, because it is an orphan with 0 
contributors, and anyone who might want it should be referred to 
"https://github.com/sbgraves237/Ecdat";.


      4.  Email all the previous project members on 
"https://r-forge.r-project.org/projects/ecdat/"; to tell them what I've 
done, in case they want to do anything more with this in the future.


   I believe I know how to do 1, 2, and 4, and I can probably figure 
out 3.  However, before I start on this, I felt a need to thank everyone 
who contributed to this thread and invite comments, especially if 
someone thinks I might be better off doing something different.


   Spencer Graves


On 2019-06-26 16:34, Henrik Singmann wrote:
> Whereas it is true that one has to contact GitHub to detach a GitHub 
> repository, it really is no problem (or at least was no problem in 
> 2016). I wanted to do so when I took over the maintainer role of 
> LaplacesDemon which only remained on GitHub as a fork on some other 
> person's private account. So I forked and then contacted 
> GitHub support and simply asked them to remove the "forked form" 
> reference on my new repository. They then quickly detached my 
> repository. As you can see, the "forked from" is gone: 
> https://github.com/LaplacesDemonR/LaplacesDemon
>
> In their response to my request they used the phrasing "Fork is 
> detached." which suggests that this is their preferred term for this 
> step.
>
> Best,
> Henrik
>
>
>
> Am Mi., 26. Juni 2019 um 16:38 Uhr schrieb Lionel Henry 
> mailto:lio...@rstudio.com>>:
>
>
> > On 26 Jun 2019, at 17:25, Duncan Murdoch
> mailto:murdoch.dun...@gmail.com>> wrote:
> >
> > R-Forge is mirrored on Github; see
> https://github.com/rforge/ecdat, for example.  That shows 418
> commits in its history; presumably that's the full R-forge
> history.  I think that's newer than Michael Friendly's gist.
> >
> > So I suspect (but haven't tried to do this) that migration now
> is as simple as doing a Github fork to your own Github account,
> and then basically forgetting about the R-forge stuff, or deleting
> it (and I don't know how to do that).
>
> I think it's better to avoid the Fork button in this case, because
> forks are
> treated specially in the Github UI. In this case you'll want your
> repo to
> appear as a main repo, and not a fork. AFAIK the only way to
> unfork a repo
> is to ask the Github staff to do it.
>
> So instead of forking, use the "+" button on github.com
>  and select
> "Import a repository". This supports both git and svn repos.
>
> Best,
> Lionel
> __
> R-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> -- 
> Dr. Henrik Singmann
> Assistant Professor, Department of Psychology
> University of Warwick, UK
> http://singmann.org


[[alternative HTML version deleted]]

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

Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error

[Henrik Bengtsson]

Using:

untrace(methods::conformMethod)
at <- c(12,4,3,2)
str(body(methods::conformMethod)[[at]])
## language omittedSig <- omittedSig && (signature[omittedSig] != "missing")
cc <- 0L
trace(methods::conformMethod, tracer = quote({
  cc <<- cc + 1L
  print(cc)
  if (cc == 31) {  ## manually identified
untrace(methods::conformMethod)
trace(methods::conformMethod, at = list(at), tracer = quote({
  str(list(signature = signature, mnames = mnames, fnames = fnames))
  print(ls())
  try(str(list(omittedSig = omittedSig, signature = signature)))
}))
  }
}))
loadNamespace("oligo")

gives:

Untracing function "conformMethod" in package "methods"
Tracing function "conformMethod" in package "methods"
Tracing conformMethod(signature, mnames, fnames, f, fdef, definition)
step 12,4,3,2
List of 3
 $ signature: Named chr [1:4] "TilingFeatureSet" "ANY" "ANY" "array"
  ..- attr(*, "names")= chr [1:4] "object" "subset" "target" "value"
  ..- attr(*, "package")= chr [1:4] "oligoClasses" "methods" "methods" "methods"
 $ mnames   : chr [1:2] "object" "value"
 $ fnames   : chr [1:4] "object" "subset" "target" "value"
 [1] "f"  "fdef"   "fnames" "fsig"   "imf"
 [6] "method" "mnames" "omitted""omittedSig" "sig0"
[11] "sigNames"   "signature"
List of 2
 $ omittedSig: logi [1:4] FALSE TRUE TRUE FALSE
 $ signature : Named chr [1:4] "TilingFeatureSet" "ANY" "ANY" "array"
  ..- attr(*, "names")= chr [1:4] "object" "subset" "target" "value"
  ..- attr(*, "package")= chr [1:4] "oligoClasses" "methods" "methods" "methods"
Error in omittedSig && (signature[omittedSig] != "missing") :
  'length(x) = 4 > 1' in coercion to 'logical(1)'
Error: unable to load R code in package 'oligo'

This is with:

sessionInfo()
R version 3.6.0 Patched (2019-06-23 r76734)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS:   /home/hb/software/R-devel/R-3-6-branch/lib/R/lib/libRblas.so
LAPACK: /home/hb/software/R-devel/R-3-6-branch/lib/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.1  affxparser_1.56.0
 [3] XVector_0.24.0  splines_3.6.0
 [5] GenomicRanges_1.36.0BiocGenerics_0.30.0
 [7] zlibbioc_1.30.0 IRanges_2.18.1
 [9] bit_1.1-14  BiocParallel_1.18.0
[11] lattice_0.20-38 foreach_1.4.4
[13] blob_1.1.1  GenomeInfoDb_1.20.0
[15] tools_3.6.0 SummarizedExperiment_1.14.0
[17] parallel_3.6.0  grid_3.6.0
[19] Biobase_2.44.0  ff_2.2-14
[21] DBI_1.0.0   iterators_1.0.10
[23] oligoClasses_1.46.0 matrixStats_0.54.0
[25] digest_0.6.19   bit64_0.9-7
[27] preprocessCore_1.46.0   affyio_1.54.0
[29] Matrix_1.2-17   GenomeInfoDbData_1.2.1
[31] BiocManager_1.30.4  codetools_0.2-16
[33] S4Vectors_0.22.0bitops_1.0-6
[35] RCurl_1.95-4.12 memoise_1.1.0
[37] RSQLite_2.1.1   DelayedArray_0.10.0
[39] compiler_3.6.0  Biostrings_2.52.0
[41] stats4_3.6.0

/Henrik

On Thu, Jun 27, 2019 at 8:16 AM Martin Maechler
 wrote:
>
> > peter dalgaard
> > on Thu, 27 Jun 2019 16:23:14 +0200 writes:
>
> > Henrik,
> > If a minimal reprex is hard to construct, could you perhaps instrument 
> your version of R to include a browser() call at the start of the
>
> > else if(!all(signature[omittedSig] == "missing")) {
>
> > branch, run the code that triggers the issue for you (and must hit that 
> branch) and tell us what the "signature" and  "omittedSig" objects look like 
> at that point?
>
> > Bonus points for figuring out why it is needed to use numerical 
> indexing in
>
> > omittedSig <- seq_along(omittedSig)[omittedSig]
> > signature[omittedSig] <- "missing" # logical index will extend 
> signature!
>
> > (I'm sure there is a valid reason, I just don't get it...)
>
> > -pd
>
> I've also have mused over that question...
> and I had assumed some difference in the case the original
> omittedSig contains NAs ... but that's NOT true actually, see:
>
>   > sign2 <- signatures <- LETTERS
>   > omittedSig <- LETTERS < "K"
>   > omittedSig[c(8,18)] <- NA # now have an omittedSig with {T, F, NA}
>   > iSig <- seq_along(omittedSig)[omittedSig]
>   > sign2[iSig] <- "missing"
>   > signatures[omittedSig] <- "missing"
>   > identical(sign2, signatures)
>   [1] TRUE
>   >
>
> so I still don't see the case where it makes a difference.
>
> Martin
>
> >> On 25 Jun 2019, at 09:44 , peter dalgaard  wrote:

Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error

[Martin Maechler]

> peter dalgaard 
> on Thu, 27 Jun 2019 16:23:14 +0200 writes:

> Henrik,
> If a minimal reprex is hard to construct, could you perhaps instrument 
your version of R to include a browser() call at the start of the 

> else if(!all(signature[omittedSig] == "missing")) {

> branch, run the code that triggers the issue for you (and must hit that 
branch) and tell us what the "signature" and  "omittedSig" objects look like at 
that point?

> Bonus points for figuring out why it is needed to use numerical indexing 
in 

> omittedSig <- seq_along(omittedSig)[omittedSig]
> signature[omittedSig] <- "missing" # logical index will extend signature!

> (I'm sure there is a valid reason, I just don't get it...)

> -pd

I've also have mused over that question...
and I had assumed some difference in the case the original
omittedSig contains NAs ... but that's NOT true actually, see:

  > sign2 <- signatures <- LETTERS
  > omittedSig <- LETTERS < "K"
  > omittedSig[c(8,18)] <- NA # now have an omittedSig with {T, F, NA}
  > iSig <- seq_along(omittedSig)[omittedSig]
  > sign2[iSig] <- "missing"
  > signatures[omittedSig] <- "missing"
  > identical(sign2, signatures)
  [1] TRUE
  > 

so I still don't see the case where it makes a difference.

Martin

>> On 25 Jun 2019, at 09:44 , peter dalgaard  wrote:
>> 
>> Argh! Yes you are right, the "fix" doesn't. And I fell into the same 
"hey it's a vector so && has to be wrong"-trap. So this has to be reverted to 
something that has at least failed unconspicuously for a decade Will do. 
Thanks to Martin for remaining suspicious!
>> 
>> [This code was originally from 2009, by John Chambers. It is not too 
likely that he'll remember what the intention actually was... The logic does 
escape me: An omitted signature is only an omitted signature if the signature 
of the omitted signature is not "missing"? In that case, I think 
>> 
>> omittedSig[omittedSig] <- (signature[omittedSig] != "missing")
>> 
>> might work (omittedSig[omittedSig] == TRUE, so we don't need to &. That 
is, unless there are NA issues.), but I am not at all sure that is what is 
wanted!
>> ]
>> 
>> -pd
>> 
>>> On 25 Jun 2019, at 07:16 , Henrik Bengtsson 
 wrote:
>>> 
>>> **Maybe this bug needs to be understood further before applying the
>>> patch because patch is most likely also wrong**
>>> 
>>> Because, from just looking at the expressions, I think neither the R
>>> 3.6.0 version:
>>> 
>>> omittedSig <- omittedSig && (signature[omittedSig] != "missing")
>>> 
>>> nor the patched version (I proposed):
>>> 
>>> omittedSig <- omittedSig & (signature[omittedSig] != "missing")
>>> 
>>> can be correct.  For a starter, 'omittedSig' is a logical vector.  We
>>> see that 'omittedSig' is used to subset 'signature'.  In other words,
>>> the length of 'signature[omittedSig]' and hence the length of
>>> '(signature[omittedSig] != "missing")' will equal sum(omittedSig),
>>> i.e. the length will be in {0,1,...,length(omittedSig)}.
>>> 
>>> The R 3.6.0 version with '&&' is not correct because '&&' requires
>>> length(omittedSig) == 1L and sum(omittedSig) == 1L, which is unlikely
>>> to be the original intention.
>>> 
>>> The patched version with '&' is most likely not correct either because
>>> 'LHS & RHS' assume length(LHS) == length(RHS), unless it relies on the
>>> auto-expansion of either vector.  So, for the '&' version to be
>>> correct, it basically requires that length(omittedSig) = length(LHS) =
>>> length(RHS) = sum(omittedSig), which also sounds unlikely to be the
>>> original intention.
>>> 
>>> Disclaimer: Please note that I have not at all studied the rest of the
>>> function, so the above is just based on that single line plus
>>> debugging that 'omittedSig' is a logical vector.
>>> 
>>> Martin, I don't have the time to dive into this further.  Though I did
>>> try to see if it happened when one of oligo's dependencies were
>>> loaded, but that was not the case. It kicks in when oligo is loaded.
>>> FYI, I can also replicate your non-replicatation on another R 3.6.0
>>> version. I'll see if I can narrow down what's different, e.g.
>>> comparing sessionInfo():s, etc.  However, I want to reply with
>>> findings above asap due to the R 3.6.1 release and you might roll back
>>> the patch (since it might introduce other bugs as Peter mentioned).
>>> 
>>> /Henrik
>>> 
>>> 
>>> On Mon, Jun 24, 2019 at 3:05 AM Martin Maechler
>>>  wrote:
 
> Henrik Bengtsson via R-core
> on Sun, 23 Jun 2019 11:29:58 -0700 writes:
 
> Thank you.
> To correct myself, I can indeed reproduce this with R --vanilla too.
> A reproducible example is:
 
> $ R --vanilla
  

Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true error

[peter dalgaard]

Henrik,

If a minimal reprex is hard to construct, could you perhaps instrument your 
version of R to include a browser() call at the start of the 

else if(!all(signature[omittedSig] == "missing")) {

branch, run the code that triggers the issue for you (and must hit that branch) 
and tell us what the "signature" and  "omittedSig" objects look like at that 
point?

Bonus points for figuring out why it is needed to use numerical indexing in 

omittedSig <- seq_along(omittedSig)[omittedSig]
signature[omittedSig] <- "missing" # logical index will extend 
signature!

(I'm sure there is a valid reason, I just don't get it...)

-pd

> On 25 Jun 2019, at 09:44 , peter dalgaard  wrote:
> 
> Argh! Yes you are right, the "fix" doesn't. And I fell into the same "hey 
> it's a vector so && has to be wrong"-trap. So this has to be reverted to 
> something that has at least failed unconspicuously for a decade Will do. 
> Thanks to Martin for remaining suspicious!
> 
> [This code was originally from 2009, by John Chambers. It is not too likely 
> that he'll remember what the intention actually was... The logic does escape 
> me: An omitted signature is only an omitted signature if the signature of the 
> omitted signature is not "missing"? In that case, I think 
> 
> omittedSig[omittedSig] <- (signature[omittedSig] != "missing")
> 
> might work (omittedSig[omittedSig] == TRUE, so we don't need to &. That is, 
> unless there are NA issues.), but I am not at all sure that is what is wanted!
> ]
> 
> -pd
> 
>> On 25 Jun 2019, at 07:16 , Henrik Bengtsson  
>> wrote:
>> 
>> **Maybe this bug needs to be understood further before applying the
>> patch because patch is most likely also wrong**
>> 
>> Because, from just looking at the expressions, I think neither the R
>> 3.6.0 version:
>> 
>> omittedSig <- omittedSig && (signature[omittedSig] != "missing")
>> 
>> nor the patched version (I proposed):
>> 
>> omittedSig <- omittedSig & (signature[omittedSig] != "missing")
>> 
>> can be correct.  For a starter, 'omittedSig' is a logical vector.  We
>> see that 'omittedSig' is used to subset 'signature'.  In other words,
>> the length of 'signature[omittedSig]' and hence the length of
>> '(signature[omittedSig] != "missing")' will equal sum(omittedSig),
>> i.e. the length will be in {0,1,...,length(omittedSig)}.
>> 
>> The R 3.6.0 version with '&&' is not correct because '&&' requires
>> length(omittedSig) == 1L and sum(omittedSig) == 1L, which is unlikely
>> to be the original intention.
>> 
>> The patched version with '&' is most likely not correct either because
>> 'LHS & RHS' assume length(LHS) == length(RHS), unless it relies on the
>> auto-expansion of either vector.  So, for the '&' version to be
>> correct, it basically requires that length(omittedSig) = length(LHS) =
>> length(RHS) = sum(omittedSig), which also sounds unlikely to be the
>> original intention.
>> 
>> Disclaimer: Please note that I have not at all studied the rest of the
>> function, so the above is just based on that single line plus
>> debugging that 'omittedSig' is a logical vector.
>> 
>> Martin, I don't have the time to dive into this further.  Though I did
>> try to see if it happened when one of oligo's dependencies were
>> loaded, but that was not the case. It kicks in when oligo is loaded.
>> FYI, I can also replicate your non-replicatation on another R 3.6.0
>> version. I'll see if I can narrow down what's different, e.g.
>> comparing sessionInfo():s, etc.  However, I want to reply with
>> findings above asap due to the R 3.6.1 release and you might roll back
>> the patch (since it might introduce other bugs as Peter mentioned).
>> 
>> /Henrik
>> 
>> 
>> On Mon, Jun 24, 2019 at 3:05 AM Martin Maechler
>>  wrote:
>>> 
 Henrik Bengtsson via R-core
   on Sun, 23 Jun 2019 11:29:58 -0700 writes:
>>> 
 Thank you.
 To correct myself, I can indeed reproduce this with R --vanilla too.
 A reproducible example is:
>>> 
 $ R --vanilla
 R version 3.6.0 Patched (2019-05-31 r76629) -- "Planting of a Tree"
 ...
> Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "true")
> loadNamespace("oligo")
 Error in omittedSig && (signature[omittedSig] != "missing") :
 'length(x) = 4 > 1' in coercion to 'logical(1)'
 Error: unable to load R code in package ‘oligo’
>>> 
 /Henrik
>>> 
>>> Thank you Henrik, for the report, etc, but
>>> hmm... after loading the oligo package, almost 40 (non
>>> base+Recommended) packages have been loaded as well, which hence
>>> need to have been installed before, too ..
>>> which is not quite a "vanilla repr.ex." in my view
>>> 
>>> Worse, I cannot reproduce :
>>> 
 Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "true")
 Sys.getenv("_R_CHECK_LENGTH_1_LOGIC2_")
>>>   [1] "true"
 debugonce(conformMethod)
 loadNamespace("oligo")
>>>   
>>>   Warning messages:
>>>   1: multiple methods tables found for ‘rowSums’
>>>   2: multiple methods tables found for ‘colSum

Re: [Rd] Seg fault stats::runmed

[Martin Maechler]

> Martin Maechler 
> on Fri, 5 Oct 2018 12:16:37 +0200 writes:

> Hilmar Berger 
> on Fri, 5 Oct 2018 10:17:49 +0200 writes:

>> Dear all, I just found this issue:

>> I just found this issue:

>> dd1 = c(rep(NaN,82), rep(-1, 144), rep(1, 74))
>> xx = runmed(dd1, 21)

>>> R crashes reproducibly in R 3.4.3, R3.4.4 (Ubuntu 14.04/Ubuntu 16.04)

> and also in the latest development version (we call "R-devel").

> THank you very much, Hilmar!

> I will have a look, to ensure missing values (incl NaN) are
> handled propertly.

That "look" had several parts to it, with long breaks in between;
finally Hilmar kindly asked me privately, and I committed
changes to R-devel (and R 3.6.0 patched), with NEWS entry

* runmed(x, *) when x contains missing values now works for
  algorithm="Stuetzle", also based on smoothEnds(y) working with
  NA's, and no longer segfaults for the "Turlach" algorithm;
  reported by Hilmar Berger.

but the changes were not at all sufficient to correctly deal
with NA / NaN's in runmed() --- and hence the above NEWS entry
was "fake news" as some may call it.

So, the last 2 weeks or so, I've spent several working days and
some extra hours trying to get this going. {several tries proved
to be insufficient, logically wrong, too optimistic, ...}

In the end, I've implemented a simplistic "imputation"-scheme
for the default case, *and* also added a new optional argument
'na.action' to runmed(),
and committed this half an hour ago :


r76744 | maechler | 2019-06-27 15:51:04 +0200 (Thu, 27. Jun 2019) 

   M doc/NEWS.Rd
   M src/library/stats/R/runmed.R
   M src/library/stats/man/runmed.Rd
   M src/library/stats/man/smoothEnds.Rd
   M src/library/stats/src/Srunmed.c
   M src/library/stats/src/Trunmed.c
   M src/library/stats/src/init.c
   M src/library/stats/src/statsR.h
   M tests/Examples/stats-Ex.Rout.save
   M tests/reg-tests-1d.R

runmed(, "Turlach") did still seg.fault. Now, NEWS entry (76682) should be 
true; new argument `na.action = ".."` determines *how* NA/NaN are treated


As this does prevent seg.faults, and if it is acceptable to the
release process, this may also make it into the upcoming R 3.6.1.

--
Martin Maechler
ETH Zurich and R Core Team

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

Re: [Rd] R-Forge > GitHub?

[Spencer Graves]

 � Thanks.� I'm still having problems:


 ��� ��� 1.� I went to "github.com" and logged in with my standard 
GitHub account


 ��� ��� 2.� Then I clicked "+" in the upper right, just left of my 
GitHub ID icon, and selected "Import a repository", as Lionel suggested.


 ��� ��� 3.� " Your old repository�s clone URL" = 
"https://r-forge.r-project.org/projects/ecdat/"; with "Name" = "Ecdat".


 ��� �� �� ��� ** >> This failed, first giving me a 500 failure 
code, then reporting " Repository creation failed."� When I tried it 
again, I got, "The repository Ecdat already exists on this account."


 � What do you suggest I try next?


 � Thanks,
 � Spencer


On 2019-06-26 12:02, Lionel Henry wrote:
> I think all 3 issues are solved by:
>
> 1. Use the "+" button on github.com �and select 
> "Import a repository".
> 2. Pass the URL of your SVN repo.
>
> Lionel
>
>> On 26 Jun 2019, at 18:58, Spencer Graves > > wrote:
>>
>> � Thanks to Duncan, Lionel and Henrik for their quick replies. I 
>> have further questions:
>>
>>
>> ��� ��  1.� Will GitHub automatically transfer the commits I made 
>> to R-Forge in the past couple of days? R-Forge is now at Rev. 420, 
>> and GitHub is still at 418. Will 419 and 420 be automatically 
>> mirrored onto "https://github.com/rforge/ecdat"; sometime in the next 
>> 24 hours or so?� Is there something easy I can do to force that update?
>>
>>
>> ��� ��  2.� Is there a way to make this GitHub version the 
>> master?� It currently says it is a 'Read-only mirror of "ecdat" from 
>> r-forge SVN.'� I can probably change 
>> "r-forge.r-project.org/projects/ecdat 
>> " so I'm the only one 
>> authorized to make changes there and then stop committing changes 
>> there.� However, before I do that, I'd want to make sure I can commit 
>> directly to the GitHub version, etc.
>>
>>
>> ��� ��  3.� How can I make myself the owner and a contributor for 
>> the GitHub version?� I'm a "Project Admin" on the R-Forge version, 
>> but currently no one can make any changes to the GitHub version 
>> except via R-Forge.� There must be a recommended migration process.
>>
>>
>> � I could create a separate version of this package on GitHub, 
>> but all the history would be lost.
>>
>>
>> � Thanks again,
>> � Spencer Graves
>>
>>
>> On 2019-06-26 10:35, Lionel Henry wrote:
 On 26 Jun 2019, at 17:25, Duncan Murdoch >>> > wrote:

 R-Forge is mirrored on Github; see https://github.com/rforge/ecdat, 
 for example. �That shows 418 commits in its history; presumably 
 that's the full R-forge history. �I think that's newer than Michael 
 Friendly's gist.

 So I suspect (but haven't tried to do this) that migration now is 
 as simple as doing a Github fork to your own Github account, and 
 then basically forgetting about the R-forge stuff, or deleting it 
 (and I don't know how to do that).
>>> I think it's better to avoid the Fork button in this case, because 
>>> forks are
>>> treated specially in the Github UI. In this case you'll want your 
>>> repo to
>>> appear as a main repo, and not a fork. AFAIK the only way to unfork 
>>> a repo
>>> is to ask the Github staff to do it.
>>>
>>> So instead of forking, use the "+" button on github.com 
>>>  and select
>>> "Import a repository". This supports both git and svn repos.
>>>
>>> Best,
>>> Lionel
>>
>


[[alternative HTML version deleted]]

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

Re: [Rd] R-Forge > GitHub?

[Spencer Graves]

  Thanks to Duncan, Lionel and Henrik for their quick replies. I 
have further questions:



        1.  Will GitHub automatically transfer the commits I made 
to R-Forge in the past couple of days?  R-Forge is now at Rev. 420, and 
GitHub is still at 418.  Will 419 and 420 be automatically mirrored onto 
"https://github.com/rforge/ecdat"; sometime in the next 24 hours or so?  
Is there something easy I can do to force that update?



        2.  Is there a way to make this GitHub version the master?  
It currently says it is a 'Read-only mirror of "ecdat" from r-forge 
SVN.'  I can probably change "r-forge.r-project.org/projects/ecdat" so 
I'm the only one authorized to make changes there and then stop 
committing changes there.  However, before I do that, I'd want to make 
sure I can commit directly to the GitHub version, etc.



        3.  How can I make myself the owner and a contributor for 
the GitHub version?  I'm a "Project Admin" on the R-Forge version, but 
currently no one can make any changes to the GitHub version except via 
R-Forge.  There must be a recommended migration process.



  I could create a separate version of this package on GitHub, but 
all the history would be lost.



  Thanks again,
  Spencer Graves


On 2019-06-26 10:35, Lionel Henry wrote:

On 26 Jun 2019, at 17:25, Duncan Murdoch  wrote:

R-Forge is mirrored on Github; see https://github.com/rforge/ecdat, for 
example.  That shows 418 commits in its history; presumably that's the full 
R-forge history.  I think that's newer than Michael Friendly's gist.

So I suspect (but haven't tried to do this) that migration now is as simple as 
doing a Github fork to your own Github account, and then basically forgetting 
about the R-forge stuff, or deleting it (and I don't know how to do that).

I think it's better to avoid the Fork button in this case, because forks are
treated specially in the Github UI. In this case you'll want your repo to
appear as a main repo, and not a fork. AFAIK the only way to unfork a repo
is to ask the Github staff to do it.

So instead of forking, use the "+" button on github.com and select
"Import a repository". This supports both git and svn repos.

Best,
Lionel


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

Re: [Rd] R-Forge > GitHub?

[Duncan Murdoch]

On 26/06/2019 1:38 p.m., Spencer Graves wrote:

   Thanks.  I'm still having problems:


         1.  I went to "github.com" and logged in with my standard 
GitHub account



         2.  Then I clicked "+" in the upper right, just left of my 
GitHub ID icon, and selected "Import a repository", as Lionel suggested.



         3.  " Your old repository’s clone URL" = 
"https://r-forge.r-project.org/projects/ecdat/"; with "Name" = "Ecdat".



               ** >> This failed, first giving me a 500 failure 
code, then reporting " Repository creation failed."  When I tried it 
again, I got, "The repository Ecdat already exists on this account."



   What do you suggest I try next?


How complicated is your R-forge repository?  Are you hosting more than 
one package there?  Are you using branches and tags?


If it's really simple, I'd recommend importing from the Github read-only 
copy, rather than from R-forge.  R-forge has a non-standard setup for 
repositories, and you probably don't want to import that to Github. (A 
few years ago devtools didn't even work properly on R-forge because of 
the non-standard setup.  I don't know if Github will be able to handle 
it.)  The creator of "https://github.com/rforge/ecdat"; simplified things 
a lot, ignoring branches, tags, etc.  For most repositories, this is fine.


Your first step will probably be to delete the existing ecdat repository 
which showed up in your second error message. Instructions for that are 
here:  https://help.github.com/en/articles/deleting-a-repository.


Duncan Murdoch




   Thanks,
   Spencer


On 2019-06-26 12:02, Lionel Henry wrote:

I think all 3 issues are solved by:

1. Use the "+" button on github.com  and select 
"Import a repository".

2. Pass the URL of your SVN repo.

Lionel

On 26 Jun 2019, at 18:58, Spencer Graves > wrote:


  Thanks to Duncan, Lionel and Henrik for their quick replies. I 
have further questions:



        1.  Will GitHub automatically transfer the commits I made 
to R-Forge in the past couple of days? R-Forge is now at Rev. 420, 
and GitHub is still at 418. Will 419 and 420 be automatically 
mirrored onto "https://github.com/rforge/ecdat"; sometime in the next 
24 hours or so?  Is there something easy I can do to force that update?



        2.  Is there a way to make this GitHub version the 
master?  It currently says it is a 'Read-only mirror of "ecdat" from 
r-forge SVN.'  I can probably change 
"r-forge.r-project.org/projects/ecdat 
" so I'm the only one 
authorized to make changes there and then stop committing changes 
there.  However, before I do that, I'd want to make sure I can commit 
directly to the GitHub version, etc.



        3.  How can I make myself the owner and a contributor for 
the GitHub version?  I'm a "Project Admin" on the R-Forge version, 
but currently no one can make any changes to the GitHub version 
except via R-Forge.  There must be a recommended migration process.



  I could create a separate version of this package on GitHub, 
but all the history would be lost.



  Thanks again,
  Spencer Graves


On 2019-06-26 10:35, Lionel Henry wrote:
On 26 Jun 2019, at 17:25, Duncan Murdoch > wrote:


R-Forge is mirrored on Github; see https://github.com/rforge/ecdat, 
for example.  That shows 418 commits in its history; presumably 
that's the full R-forge history.  I think that's newer than Michael 
Friendly's gist.


So I suspect (but haven't tried to do this) that migration now is 
as simple as doing a Github fork to your own Github account, and 
then basically forgetting about the R-forge stuff, or deleting it 
(and I don't know how to do that).
I think it's better to avoid the Fork button in this case, because 
forks are
treated specially in the Github UI. In this case you'll want your 
repo to
appear as a main repo, and not a fork. AFAIK the only way to unfork 
a repo

is to ask the Github staff to do it.

So instead of forking, use the "+" button on github.com 
 and select

"Import a repository". This supports both git and svn repos.

Best,
Lionel








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

Re: [Rd] r-project.org dns

[Prof Brian Ripley]

On 26/06/2019 21:13, Tim Keitt wrote:

Sorry if this was already discussed. I notice that r-project.org is not
found in dns lookups today. (At least for me -- I tried some online web
look services as well.)

THK


We knew, but all the R listservers were also affected.  The name servers 
in Vienna have been restarted and DNS is slowly recovering (including 
delivering your message).


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

[Rd] r-project.org dns

[Tim Keitt]

Sorry if this was already discussed. I notice that r-project.org is not
found in dns lookups today. (At least for me -- I tried some online web
look services as well.)

THK

[[alternative HTML version deleted]]

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