Re: [Bioc-devel] GitHub and Bioc sync: issue with dup commit for the sva package

[Turaga, Nitesh]

Hi Leo,

You are right in that you cannot “force” push to git.bioconductor.org.  I’ve 
just done this for you.

The git history looks clean and you can sync your Github and Bioc 
(http://bioconductor.org/developers/how-to/git/sync-existing-repositories/) for 
any further changes without any issues now. 

Let me know if you have trouble. 

Best regards,

Nitesh 


> On Aug 30, 2018, at 3:33 AM, Claire Ruberman  wrote:
> 
> Thank you, Leo!
> 
> On Mon, Aug 27, 2018 at 1:53 PM Leonardo Collado Torres  
> wrote:
> Hi Nitesh,
> 
> After looking more closely, I went with option 1 that you clearly
> outlined below. The cherry picked version of the history is now the
> origin/master one at
> https://github.com/jtleek/sva-devel/commits/master. From
> http://bioconductor.org/developers/how-to/git/resolve-duplicate-commits/
> my understanding is that now you have to force the Bioconductor git
> history (upstream/master with the default setup) to match the one from
> the sva-devel GitHub repo.
> 
> The only complicated commit was
> https://github.com/jtleek/sva-devel/commit/e6b80f62d494f77465650cf3d624feaf8913e837
> where I had to use the "theirs" strategy for many files.
> 
> At the end I added this commit
> https://github.com/jtleek/sva-devel/commit/05cfab55c893b428061ab703f3abd235889a
> that bumps the version of the package to 3.29.1 on bioc-devel to
> propagate Claire's recent changes.
> 
> Best,
> Leo
> 
> PS I tried the git push -f upstream/master out of curiousity, and yup,
> I can't do it:
> 
> $ git push -f upstream master
> Counting objects: 111, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (54/54), done.
> Writing objects: 100% (111/111), 19.58 KiB | 2.80 MiB/s, done.
> Total 111 (delta 83), reused 62 (delta 56)
> remote: Resolving deltas: 100% (83/83), completed with 38 local objects.
> remote: FATAL: + refs/heads/master packages/sva l.collado-torres
> DENIED by fallthru
> remote: error: hook declined to update refs/heads/master
> To git.bioconductor.org:packages/sva.git
>  ! [remote rejected] master -> master (hook declined)
> error: failed to push some refs to 
> 'g...@git.bioconductor.org:packages/sva.git'
> 
> PS2 I did push the master_backup branch to GitHub just in case we need
> it later https://github.com/jtleek/sva-devel/tree/master_backup
> 
> 
> On Sat, Aug 25, 2018 at 2:00 AM Turaga, Nitesh
>  wrote:
> >
> > Hi Leo,
> >
> > I’ll try to help you with this issue.
> >
> > The duplicates commit you have on your package “sva” come from the pre-git 
> > era of Bioconductor.  There are three ways we can fix this,
> >
> > 1,
> >
> > You fix your GitHub repo by removing the duplicate commits. They happen 
> > only after this commit.
> >
> > commit d12b53824915f0ff7b7906043c7fc9237521e8f3
> > Author: Kipper Fletez-Brant 
> > Date:   Sat Apr 22 10:42:29 2017 -0400
> >
> > actually did it
> >
> >
> > You can do the cherry-picking of the commits (only one from a set of 
> > duplicate commits, one after the other to construct your git history). It 
> > is outlined in this document here,
> >
> > 
> > http://bioconductor.org/developers/how-to/git/resolve-duplicate-commits/.
> >
> > If you choose this method, I can help with any questions you may have.
> >
> > Some help if you decide to choose this route,
> >
> > A.
> >
> > You might face issues with this commit (7e4aa44 Merge pull request 
> > #26 from cafletezbrant/master) while doing the cherry-pick.
> > You can ignore this, because the commits themselves will be in the 
> > git history.
> >
> > d12b538 actually did it
> > 7cedd49 needed to use tcrossprod(t(...)) a bunch
> >
> >
> > B.
> >
> > If you hit a lot of merge conflicts while doing the cherry-pick, 
> > the best way I’ve gotten used to is by using
> >
> > `git mergetool`.
> >
> > (I personally use the option `git mergetool -t vimdiff`, but feel 
> > free to use whatever merge tool you’d like)
> >
> > C.
> >
> > Make sure you cherry-pick the RELEASE commits which come from the 
> > core team while doing the cherry-pick process.
> >
> > 2,
> >
> > I can fix the bioconductor repo on my end to show no duplicate commits. 
> > Then you’d have to force your Github master branch to be the same as the 
> > Bioconductor repo and then put Claire’s commits on top of them. This is a 
> > slightly less optimal solution because I might make some mistakes resolving 
> > the conflicts, since I don’t know the details of code.
> >
> > 3,
> >
> > Since the issue of duplicate commits was pre-git era, we can just ignore 
> > the duplicates. It is pretty straightforward to disable the duplicate 
> > commit check, but it should only be a worst case. I don’t recommend this 
> > for your repo because there are very few issues and it seems we can resolve 
> > them. I reserve this option for packages which have extensively fractured 
> > their git history.
> >
> >
> > Best 

[Rd] Detecting whether a process exists or not by its PID?

[Henrik Bengtsson]

Hi, I'd like to test whether a (localhost) PSOCK cluster node is still
running or not by its PID, e.g. it may have crashed / core dumped.
I'm ok with getting false-positive results due to *another* process
with the same PID has since started.

I can the PID of each cluster nodes by querying them for their
Sys.getpid(), e.g.

pids <- parallel::clusterEvalQ(cl, Sys.getpid())

Is there a function in core R for testing whether a process with a
given PID exists or not? From trial'n'error, I found that on Linux:

  pid_exists <- function(pid) as.logical(tools::pskill(pid, signal = 0L))

returns TRUE for existing processes and FALSE otherwise, but I'm not
sure if I can trust this.  It's not a documented feature in
?tools::pskill, which also warns about 'signal' not being standardized
across OSes.

The other Linux alternative I can imagine is:

  pid_exists <- function(pid) system2("ps", args = c("--pid", pid),
stdout = FALSE) == 0L

Can I expect this to work on macOS as well?  What about other *nix systems?

And, finally, what can be done on Windows?

I'm sure there are packages on CRAN that provides this, but I'd like
to keep dependencies at a minimum.

I appreciate any feedback. Thxs,

Henrik

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

Re: [Rd] build package with unicode (farsi) strings

[Hadley Wickham]

On Thu, Aug 30, 2018 at 2:11 AM Thierry Onkelinx
 wrote:
>
> Dear Farid,
>
> Try using the ASCII notation. letters_fa <- c("\u0627", "\u0641"). The full
> code table is available at https://www.utf8-chartable.de

It's a little easier to do this with code:

letters_fa <- c('الف','ب','پ','ت','ث','ج','چ','ح','خ','ر','ز','د')
writeLines(stringi::stri_escape_unicode(letters_fa))
#> \u0627\u0644\u0641
#> \u0628
#> \u067e
#> \u062a
#> \u062b
#> \u062c
#> \u0686
#> \u062d
#> \u062e
#> \u0631
#> \u0632
#> \u062f

Hadley

-- 
http://hadley.nz

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Hadley Wickham]

On Thu, Aug 30, 2018 at 10:58 AM Martin Maechler
 wrote:
>
> > Joris Meys
> > on Thu, 30 Aug 2018 14:48:01 +0200 writes:
>
> > On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth
> >  wrote:
> >> Note that `||` and `&&` have never been symmetric:
> >>
> >> TRUE || stop() # returns TRUE stop() || TRUE # returns an
> >> error
> >>
> >>
> > Fair point. So the suggestion would be to check whether x
> > is of length 1 and whether y is of length 1 only when
> > needed. I.e.
>
> > c(TRUE,FALSE) || TRUE
>
> > would give an error and
>
> > TRUE || c(TRUE, FALSE)
>
> > would pass.
>
> > Thought about it a bit more, and I can't come up with a
> > use case where the first line must pass. So if the short
> > circuiting remains and the extra check only gives a small
> > performance penalty, adding the error could indeed make
> > some bugs more obvious.
>
> I agree "in theory".
> Thank you, Henrik, for bringing it up!
>
> In practice I think we should start having a warning signalled.
> I have checked the source code in the mean time, and the check
> is really very cheap
> { because it can/should be done after checking isNumber(): so
>   then we know we have an atomic and can use XLENGTH() }
>
>
> The 0-length case I don't think we should change as I do find
> NA (is logical!) to be an appropriate logical answer.

Can you explain your reasoning a bit more here? I'd like to understand
the general principle, because from my perspective it's more
parsimonious to say that the inputs to || and && must be length 1,
rather than to say that inputs could be length 0 or length 1, and in
the length 0 case they are replaced with NA.

Hadley

-- 
http://hadley.nz

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Joris Meys]

On Thu, Aug 30, 2018 at 5:58 PM Martin Maechler 
wrote:

>
> I agree "in theory".
> Thank you, Henrik, for bringing it up!
>
> In practice I think we should start having a warning signalled.
>

I agree. I wouldn't know who would count on the automatic selection of the
first value, but better safe than sorry.


> I have checked the source code in the mean time, and the check
> is really very cheap
> { because it can/should be done after checking isNumber(): so
>   then we know we have an atomic and can use XLENGTH() }
>
>
That was my idea as well after going through the source code. I didn't want
to state it as I don't know enough of the code base and couldn't see if
there were complications I missed. Thank you for confirming!

Cheers
Joris
-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Rui Barradas]

Hello,

Inline.

Às 16:44 de 30/08/2018, William Dunlap via R-devel escreveu:

Should the following two functions should always give the same result,
except for possible differences in the 'call' component of the warning
or error message?:

   f0 <- function(x, y) x || y
   f1 <- function(x, y) if (x) { TRUE } else { if (y) {TRUE } else { FALSE }
}

And the same for the 'and' version?

   g0 <- function(x, y) x && y
   g1 <- function(x, y) if (x) { if (y) { TRUE } else { FALSE } } else {
FALSE }

The proposal is to make them act the same when length(x) or length(y) is
not 1.
Should they also act the same when x or y is NA?  'if (x)' currently stops
if is.na(x)
and 'x||y' does not.  Or should we continue with 'if' restricted to
bi-valued
logical and '||' and '&&' handling tri-valued logic?


I expect R to continue to do


f0(FALSE, NA)# [1] NA
f0(NA, FALSE)# [1] NA

g0(TRUE, NA)# [1] NA
g0(NA, TRUE)# [1] NA

f1(FALSE, NA)
#Error in if (y) { : missing value where TRUE/FALSE needed
f1(NA, FALSE)
#Error in if (x) { : missing value where TRUE/FALSE needed

g1(TRUE, NA)
#Error in if (x) { : missing value where TRUE/FALSE needed
g1(NA, TRUE)
#Error in if (x) { : missing value where TRUE/FALSE needed



Please don't change this.
There's more to the logical operators than the operands' lengths. That 
issue needs to be fixed but it doesn't mean a radical change should happen.
And the same goes for 'if'. Here the problem is completely different, 
there's more to 'if' than '||' and '&&'. Any change should be done with 
increased care. (Which I'm sure will, as always.)


Rui Barradas






Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Aug 30, 2018 at 7:16 AM, Hadley Wickham  wrote:


I think this is an excellent idea as it eliminates a situation which
is almost certainly user error. Making it an error would break a small
amount of existing code (even if for the better), so perhaps it should
start as a warning, but be optionally upgraded to an error. It would
be nice to have a fixed date (R version) in the future when the
default will change to error.

In an ideal world, I think the following four cases should all return
the same error:

if (logical()) 1
#> Error in if (logical()) 1: argument is of length zero
if (c(TRUE, TRUE)) 1
#> Warning in if (c(TRUE, TRUE)) 1: the condition has length > 1 and only
the
#> first element will be used
#> [1] 1

logical() || TRUE
#> [1] TRUE
c(TRUE, TRUE) || TRUE
#> [1] TRUE

i.e. I think that `if`, `&&`, and `||` should all check that their
input is a logical (or numeric) vector of length 1.

Hadley

On Tue, Aug 28, 2018 at 10:03 PM Henrik Bengtsson
 wrote:


# Issue

'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here
using R 3.5.1),


c(TRUE, TRUE) || FALSE

[1] TRUE

c(TRUE, FALSE) || FALSE

[1] TRUE

c(TRUE, NA) || FALSE

[1] TRUE

c(FALSE, TRUE) || FALSE

[1] FALSE

This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
same) and it also applies to 'x && y'.

Note also how the above truncation of 'x' is completely silent -
there's neither an error nor a warning being produced.


# Discussion/Suggestion

Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
mistake.  Either the code is written assuming 'x' and 'y' are scalars,
or there is a coding error and vectorized versions 'x | y' and 'x & y'
were intended.  Should 'x || y' always be considered an mistake if
'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
or an error?  For instance,
'''r

x <- c(TRUE, TRUE)
y <- FALSE
x || y


Error in x || y : applying scalar operator || to non-scalar elements
Execution halted

What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today
'x || y' returns 'NA' in such cases, e.g.


logical(0) || c(FALSE, NA)

[1] NA

logical(0) || logical(0)

[1] NA

logical(0) && logical(0)

[1] NA

I don't know the background for this behavior, but I'm sure there is
an argument behind that one.  Maybe it's simply that '||' and '&&'
should always return a scalar logical and neither TRUE nor FALSE can
be returned.

/Henrik

PS. This is in the same vein as
https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
- in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
_R_CHECK_LENGTH_1_CONDITION_=true

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




--
http://hadley.nz

__
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] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Martin Maechler]

> Joris Meys 
> on Thu, 30 Aug 2018 14:48:01 +0200 writes:

> On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth
>  wrote:
>> Note that `||` and `&&` have never been symmetric:
>> 
>> TRUE || stop() # returns TRUE stop() || TRUE # returns an
>> error
>> 
>> 
> Fair point. So the suggestion would be to check whether x
> is of length 1 and whether y is of length 1 only when
> needed. I.e.

> c(TRUE,FALSE) || TRUE

> would give an error and

> TRUE || c(TRUE, FALSE)

> would pass.

> Thought about it a bit more, and I can't come up with a
> use case where the first line must pass. So if the short
> circuiting remains and the extra check only gives a small
> performance penalty, adding the error could indeed make
> some bugs more obvious.

I agree "in theory".
Thank you, Henrik, for bringing it up!

In practice I think we should start having a warning signalled.
I have checked the source code in the mean time, and the check
is really very cheap
{ because it can/should be done after checking isNumber(): so
  then we know we have an atomic and can use XLENGTH() }


The 0-length case I don't think we should change as I do find
NA (is logical!) to be an appropriate logical answer.

Martin Maechler
ETH Zurich and R Core team.

> Cheers Joris

> -- 
> Joris Meys Statistical consultant

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[William Dunlap via R-devel]

Should the following two functions should always give the same result,
except for possible differences in the 'call' component of the warning
or error message?:

  f0 <- function(x, y) x || y
  f1 <- function(x, y) if (x) { TRUE } else { if (y) {TRUE } else { FALSE }
}

And the same for the 'and' version?

  g0 <- function(x, y) x && y
  g1 <- function(x, y) if (x) { if (y) { TRUE } else { FALSE } } else {
FALSE }

The proposal is to make them act the same when length(x) or length(y) is
not 1.
Should they also act the same when x or y is NA?  'if (x)' currently stops
if is.na(x)
and 'x||y' does not.  Or should we continue with 'if' restricted to
bi-valued
logical and '||' and '&&' handling tri-valued logic?



Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Aug 30, 2018 at 7:16 AM, Hadley Wickham  wrote:

> I think this is an excellent idea as it eliminates a situation which
> is almost certainly user error. Making it an error would break a small
> amount of existing code (even if for the better), so perhaps it should
> start as a warning, but be optionally upgraded to an error. It would
> be nice to have a fixed date (R version) in the future when the
> default will change to error.
>
> In an ideal world, I think the following four cases should all return
> the same error:
>
> if (logical()) 1
> #> Error in if (logical()) 1: argument is of length zero
> if (c(TRUE, TRUE)) 1
> #> Warning in if (c(TRUE, TRUE)) 1: the condition has length > 1 and only
> the
> #> first element will be used
> #> [1] 1
>
> logical() || TRUE
> #> [1] TRUE
> c(TRUE, TRUE) || TRUE
> #> [1] TRUE
>
> i.e. I think that `if`, `&&`, and `||` should all check that their
> input is a logical (or numeric) vector of length 1.
>
> Hadley
>
> On Tue, Aug 28, 2018 at 10:03 PM Henrik Bengtsson
>  wrote:
> >
> > # Issue
> >
> > 'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here
> > using R 3.5.1),
> >
> > > c(TRUE, TRUE) || FALSE
> > [1] TRUE
> > > c(TRUE, FALSE) || FALSE
> > [1] TRUE
> > > c(TRUE, NA) || FALSE
> > [1] TRUE
> > > c(FALSE, TRUE) || FALSE
> > [1] FALSE
> >
> > This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
> > same) and it also applies to 'x && y'.
> >
> > Note also how the above truncation of 'x' is completely silent -
> > there's neither an error nor a warning being produced.
> >
> >
> > # Discussion/Suggestion
> >
> > Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
> > mistake.  Either the code is written assuming 'x' and 'y' are scalars,
> > or there is a coding error and vectorized versions 'x | y' and 'x & y'
> > were intended.  Should 'x || y' always be considered an mistake if
> > 'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
> > or an error?  For instance,
> > '''r
> > > x <- c(TRUE, TRUE)
> > > y <- FALSE
> > > x || y
> >
> > Error in x || y : applying scalar operator || to non-scalar elements
> > Execution halted
> >
> > What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today
> > 'x || y' returns 'NA' in such cases, e.g.
> >
> > > logical(0) || c(FALSE, NA)
> > [1] NA
> > > logical(0) || logical(0)
> > [1] NA
> > > logical(0) && logical(0)
> > [1] NA
> >
> > I don't know the background for this behavior, but I'm sure there is
> > an argument behind that one.  Maybe it's simply that '||' and '&&'
> > should always return a scalar logical and neither TRUE nor FALSE can
> > be returned.
> >
> > /Henrik
> >
> > PS. This is in the same vein as
> > https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
> > - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
> > _R_CHECK_LENGTH_1_CONDITION_=true
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> http://hadley.nz
>
> __
> 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] build package with unicode (farsi) strings

[Ista Zahn]

On Thu, Aug 30, 2018 at 3:11 AM Thierry Onkelinx
 wrote:
>
> Dear Farid,
>
> Try using the ASCII notation. letters_fa <- c("\u0627", "\u0641").

... as recommend in the manual:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Encoding-issues

Best,
Ista

The full
> code table is available at https://www.utf8-chartable.de
>
> Best regards,
>
>
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
> ///
>
> 
>
> 2018-08-28 7:17 GMT+02:00 Faridedin Cheraghi :
>
> > Hi,
> >
> > I have a R script file with Persian letters in it defined as a variable:
> >
> > #' @export
> > letters_fa <- c('الف','ب','پ','ت','ث','ج','چ','ح','خ','ر','ز','د')
> >
> > I have specified the encoding field in my DESCRIPTION file of my package.
> >
> > ...
> > Encoding: UTF-8
> > ...
> >
> > I also included Sys.setlocale(locale="Persian") in my .RProfile, so it is
> > executed when RCMD is called. However, after a BUILD and INSTALL, when I
> > access the variable from the package, the characters are not printed
> > correctly:
> > > futils::letters_fa
> >  [1] "<84><81>" "" ""
> >"" ""
> >  [6] "" "<86>" ""
> >"" ""
> > [11] "" ""
> >
> >
> > thanks
> > Farid
> >
> > [[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

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

Re: [R-pkg-devel] Changing License

[Thomas Petzoldt]

Hi,

we had a related discussion some time ago in the JSS editorial board. It 
was a long and partly emotional discussion of the pros and cons, but the 
good news was that if a code is MIT, it can be re-licensed as GPL, while 
it would not not be possible in the opposite direction (except by the 
original copyright holders).


MIT is less political and more permissive than GPL, but its disadvantage 
is that someone can take your code, create derived work and then sell 
the derived work as closed source. Even the original developers may be 
excluded from derived work, or have to pay for it.


The JSS board discussion ended with a request in 
https://www.jstatsoft.org/pages/view/authors

that

"Code needs to include the GNU General Public Licence (GPL), versions 
GPL-2 or GPL-3, or a GPL-compatible license for publication in JSS."



where MIT or BSD can be considered as GPL compatible, while packages 
with some other licenses my need explicit double-licensing by the 
copyright holder, see also:


https://en.wikipedia.org/wiki/License_compatibility

"Many of the most common free-software licenses, especially the 
permissive licenses, such as the original MIT/X license, BSD licenses 
(in the three-clause and two-clause forms, though not the original 
four-clause form), MPL 2.0, and LGPL, are GPL-compatible. That is, their 
code can be combined with a program under the GPL without conflict, and 
the new combination would have the GPL applied to the whole (but the 
other license would not so apply)."



I would therefore recommend GPL, and you don't make something wrong if 
you re-license derived work using MIT-licensed code under the GPL.


Thomas

PS: this is my personal conclusion, I am not a lawyer.

--
Dr. Thomas Petzoldt
http://tu-dresden.de/Members/thomas.petzoldt

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Hadley Wickham]

I think this is an excellent idea as it eliminates a situation which
is almost certainly user error. Making it an error would break a small
amount of existing code (even if for the better), so perhaps it should
start as a warning, but be optionally upgraded to an error. It would
be nice to have a fixed date (R version) in the future when the
default will change to error.

In an ideal world, I think the following four cases should all return
the same error:

if (logical()) 1
#> Error in if (logical()) 1: argument is of length zero
if (c(TRUE, TRUE)) 1
#> Warning in if (c(TRUE, TRUE)) 1: the condition has length > 1 and only the
#> first element will be used
#> [1] 1

logical() || TRUE
#> [1] TRUE
c(TRUE, TRUE) || TRUE
#> [1] TRUE

i.e. I think that `if`, `&&`, and `||` should all check that their
input is a logical (or numeric) vector of length 1.

Hadley

On Tue, Aug 28, 2018 at 10:03 PM Henrik Bengtsson
 wrote:
>
> # Issue
>
> 'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here
> using R 3.5.1),
>
> > c(TRUE, TRUE) || FALSE
> [1] TRUE
> > c(TRUE, FALSE) || FALSE
> [1] TRUE
> > c(TRUE, NA) || FALSE
> [1] TRUE
> > c(FALSE, TRUE) || FALSE
> [1] FALSE
>
> This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
> same) and it also applies to 'x && y'.
>
> Note also how the above truncation of 'x' is completely silent -
> there's neither an error nor a warning being produced.
>
>
> # Discussion/Suggestion
>
> Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
> mistake.  Either the code is written assuming 'x' and 'y' are scalars,
> or there is a coding error and vectorized versions 'x | y' and 'x & y'
> were intended.  Should 'x || y' always be considered an mistake if
> 'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
> or an error?  For instance,
> '''r
> > x <- c(TRUE, TRUE)
> > y <- FALSE
> > x || y
>
> Error in x || y : applying scalar operator || to non-scalar elements
> Execution halted
>
> What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today
> 'x || y' returns 'NA' in such cases, e.g.
>
> > logical(0) || c(FALSE, NA)
> [1] NA
> > logical(0) || logical(0)
> [1] NA
> > logical(0) && logical(0)
> [1] NA
>
> I don't know the background for this behavior, but I'm sure there is
> an argument behind that one.  Maybe it's simply that '||' and '&&'
> should always return a scalar logical and neither TRUE nor FALSE can
> be returned.
>
> /Henrik
>
> PS. This is in the same vein as
> https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
> - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
> _R_CHECK_LENGTH_1_CONDITION_=true
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
http://hadley.nz

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

Re: [R-pkg-devel] Changing License

[Dirk Eddelbuettel]

On 30 August 2018 at 08:34, Charles Determan wrote:
| It has come to my attention that some of the code I am distributing in one
| of my packages was previously licensed under the MIT license.  I have
| previously released my package under the GPL-3 license.  Would it be more
| appropriate for me to change the license to MIT?  I know no one here is
| likely a lawyer but I would like to hear if there is any issue in changing
| a license of a currently released package as it is my understanding that my
| package should have the MIT license instead.

It is my understanding that this is "additive" where licenses are compatible.

Look eg at R itself. It is under GPL-2+ but contains code from other folks
released under compatible licenses -- as document more precisely in this file

  https://github.com/wch/r-source/blob/trunk/doc/COPYRIGHTS

which enumerates which files (or sets of files and directories) have
different copyrights as well as licenses (these terms frequently get mangled,
this file does too).

As another reference point, Debian formalised something similar in the
prescribed format for debian/copyright files (typically installed as
/usr/share/doc/${PACKAGE}/copyright for a given package) where sets of files
are enumerated and both the copyright and license are stated.  See eg

  https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

for all the gory details.

So in short, I think you can simply include a file stating which of the files
you re-use are copyrighted by which authors and released under which
license. _Your work extending and using those files_ as contained in your
package can happily remain under GPL-3 as does the aggregation, while the
components your refer to remain in eg MIT.

Makes sense?

Dirk
#notALawyerDisclaimerIfYouNeedIt

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

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Emil Bode]

Okay, I thought you always wanted to check the length, but if we can only check 
what's evaluated I mostly agree.

I still think there's not much wrong with how length-0 logicals are treated, as 
the return of NA in cases where the value matters is enough warning I think, 
and I can imagine some code like my previous example 'x==-1 || length(x)==0', 
which wouldn't need a warning.

But we could do a check for length being >1

Greetings, Emil


On 30/08/2018, 14:55, "R-devel on behalf of Joris Meys" 
 wrote:

On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth  wrote:

> Note that `||` and `&&` have never been symmetric:
>
> TRUE || stop() # returns TRUE
> stop() || TRUE # returns an error
>
>
Fair point. So the suggestion would be to check whether x is of length 1
and whether y is of length 1 only when needed. I.e.

c(TRUE,FALSE) || TRUE

would give an error and

TRUE || c(TRUE, FALSE)

would pass.

Thought about it a bit more, and I can't come up with a use case where the
first line must pass. So if the short circuiting remains and the extra
check only gives a small performance penalty, adding the error could indeed
make some bugs more obvious.

Cheers
Joris

-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)



---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

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

[R-pkg-devel] Changing License

[Charles Determan]

R developers,

It has come to my attention that some of the code I am distributing in one
of my packages was previously licensed under the MIT license.  I have
previously released my package under the GPL-3 license.  Would it be more
appropriate for me to change the license to MIT?  I know no one here is
likely a lawyer but I would like to hear if there is any issue in changing
a license of a currently released package as it is my understanding that my
package should have the MIT license instead.

Regards,
Charles

[[alternative HTML version deleted]]

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Joris Meys]

On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth  wrote:

> Note that `||` and `&&` have never been symmetric:
>
> TRUE || stop() # returns TRUE
> stop() || TRUE # returns an error
>
>
Fair point. So the suggestion would be to check whether x is of length 1
and whether y is of length 1 only when needed. I.e.

c(TRUE,FALSE) || TRUE

would give an error and

TRUE || c(TRUE, FALSE)

would pass.

Thought about it a bit more, and I can't come up with a use case where the
first line must pass. So if the short circuiting remains and the extra
check only gives a small performance penalty, adding the error could indeed
make some bugs more obvious.

Cheers
Joris

-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Dénes Tóth]

On 08/30/2018 01:56 PM, Joris Meys wrote:

I have to agree with Emil here. && and || are short circuited like in C and
C++. That means that

TRUE || c(TRUE, FALSE)
FALSE && c(TRUE, FALSE)

cannot give an error because the second part is never evaluated. Throwing a
warning or error for

c(TRUE, FALSE) || TRUE

would mean that the operator gives a different result depending on the
order of the objects, breaking the symmetry. Also that would be undesirable.


Note that `||` and `&&` have never been symmetric:

TRUE || stop() # returns TRUE
stop() || TRUE # returns an error




Regarding logical(0): per the documentation, it is indeed so that ||, &&
and isTRUE always return a length-one logical vector. Hence the NA.

On a sidenote: there is no such thing as a scalar in R. What you call
scalar, is really a length-one vector. That seems like a detail, but is
important in understanding why this admittedly confusing behaviour actually
makes sense within the framework of R imho. I do understand your objections
and suggestions, but it would boil down to removing short circuited
operators from R.

My 2 cents.
Cheers
Joris

On Wed, Aug 29, 2018 at 5:03 AM Henrik Bengtsson 
wrote:


# Issue

'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here
using R 3.5.1),


c(TRUE, TRUE) || FALSE

[1] TRUE

c(TRUE, FALSE) || FALSE

[1] TRUE

c(TRUE, NA) || FALSE

[1] TRUE

c(FALSE, TRUE) || FALSE

[1] FALSE

This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
same) and it also applies to 'x && y'.

Note also how the above truncation of 'x' is completely silent -
there's neither an error nor a warning being produced.


# Discussion/Suggestion

Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
mistake.  Either the code is written assuming 'x' and 'y' are scalars,
or there is a coding error and vectorized versions 'x | y' and 'x & y'
were intended.  Should 'x || y' always be considered an mistake if
'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
or an error?  For instance,
'''r

x <- c(TRUE, TRUE)
y <- FALSE
x || y


Error in x || y : applying scalar operator || to non-scalar elements
Execution halted

What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today
'x || y' returns 'NA' in such cases, e.g.


logical(0) || c(FALSE, NA)

[1] NA

logical(0) || logical(0)

[1] NA

logical(0) && logical(0)

[1] NA

I don't know the background for this behavior, but I'm sure there is
an argument behind that one.  Maybe it's simply that '||' and '&&'
should always return a scalar logical and neither TRUE nor FALSE can
be returned.

/Henrik

PS. This is in the same vein as
https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
- in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
_R_CHECK_LENGTH_1_CONDITION_=true

__
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] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Dénes Tóth]

Hi,

I absolutely second Henrik's suggestion.

On 08/30/2018 01:09 PM, Emil Bode wrote:

I have to disagree, I think one of the advantages of '||' (or &&) is the lazy evaluation, 
i.e. you can use the first condition to "not care" about the second (and stop errors 
from being thrown).


I do not think Henrik's proposal implies that both arguments of `||` or 
`&&` should be evaluated before the evaluation of the condition. It 
implies that if an argument is evaluated, and its length does not equal 
one, it should return an error instead of the silent truncation of the 
argument.

So your argument is orthogonal to the issue.


So if I want to check if x is a length-one numeric with value a value between 0 and 1, I can do 
'class(x)=='numeric' && length(x)==1 && x>0 && x<1'.
In your proposal, having x=c(1,2) would throw an error or multiple warnings.
Also code that relies on the second argument not being evaluated would break, 
as we need to evaluate y in order to know length(y)
There may be some benefit in checking for length(x) only, though that could 
also cause some false positives (e.g. 'x==-1 || length(x)==0' would be a bit 
ugly, but not necessarily wrong, same for someone too lazy to write x[1] 
instead of x).

And I don’t really see the advantage. The casting to length one is (I think), a 
feature, not a bug. If I have/need a length one x, and a length one y, why not use 
'|' and '&'? I have to admit I only use them in if-statements, and if I need an 
error to be thrown when x and y are not length one, I can use the shorter versions 
and then the if throws a warning (or an error for a length-0 or NA result).

I get it that for someone just starting in R, the differences between | and || 
can be confusing, but I guess that's just the price to pay for having a 
vectorized language.


I use R for about 10 years, and use regularly `||` and `&&` for the 
standard purpose (implemented in most programming languages for the same 
purpose, that is, no evaluation of all arguments if it is not required 
to decide whether the condition is TRUE). I can not recall any single 
case when I wanted to use them for the purpose to evaluate whether the 
*first* elements of vectors fulfill the given condition.


However, I regularly write mistakenly `||` or `&&` when I actually want 
to write `|` or `&`, and have no chance to spot the error because of the 
silent truncation of the arguments.



Regards,
Denes





Best regards,
Emil Bode
  
Data-analyst
  
+31 6 43 83 89 33

emil.b...@dans.knaw.nl
  
DANS: Netherlands Institute for Permanent Access to Digital Research Resources

Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | i...@dans.knaw.nl 
 | dans.knaw.nl 

DANS is an institute of the Dutch Academy KNAW  and funding 
organisation NWO .

On 29/08/2018, 05:03, "R-devel on behalf of Henrik Bengtsson" 
 wrote:

 # Issue
 
 'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here

 using R 3.5.1),
 
 > c(TRUE, TRUE) || FALSE

 [1] TRUE
 > c(TRUE, FALSE) || FALSE
 [1] TRUE
 > c(TRUE, NA) || FALSE
 [1] TRUE
 > c(FALSE, TRUE) || FALSE
 [1] FALSE
 
 This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the

 same) and it also applies to 'x && y'.
 
 Note also how the above truncation of 'x' is completely silent -

 there's neither an error nor a warning being produced.
 
 
 # Discussion/Suggestion
 
 Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a

 mistake.  Either the code is written assuming 'x' and 'y' are scalars,
 or there is a coding error and vectorized versions 'x | y' and 'x & y'
 were intended.  Should 'x || y' always be considered an mistake if
 'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
 or an error?  For instance,
 '''r
 > x <- c(TRUE, TRUE)
 > y <- FALSE
 > x || y
 
 Error in x || y : applying scalar operator || to non-scalar elements

 Execution halted
 
 What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today

 'x || y' returns 'NA' in such cases, e.g.
 
 > logical(0) || c(FALSE, NA)

 [1] NA
 > logical(0) || logical(0)
 [1] NA
 > logical(0) && logical(0)
 [1] NA
 
 I don't know the background for this behavior, but I'm sure there is

 an argument behind that one.  Maybe it's simply that '||' and '&&'
 should always return a scalar logical and neither TRUE nor FALSE can
 be returned.
 
 /Henrik
 
 PS. This is in the same vein as

 https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
 - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
 _R_CHECK_LENGTH_1_CONDITION_=true
 
 __

 R-devel@r-project.org mailing list
 

Re: [Bioc-devel] Logolas package broken for R (3.4) users

[kushal kumar dey]

Thanks so much Valerie and Kasper for the helpful comments...I will look
into the issue as you suggested.

Best

Kushal

On Wednesday, 29 August 2018, Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> Kasper is right, you can only update code in the current release (Bioc
> 3.7) or devel (Bioc 3.8). Sorry I didn't read your question carefully
> enough. You could, however, use the AMI suggested below to attempt to
> reproduce the reported error.
>
> This is the last build report for Bioc 3.6 and Logolas is not broken:
>
>   https://www.bioconductor.org/checkResults/3.6/bioc-20180412/
>
> If you can reproduce the error (with the AMI) you probably did not have a
> comprehensive set of tests which is why the build report is green. If you
> can't reproduce the error, the people reporting problems may be using
> mismatched R/Bioconductor package versions. The output of their
> sessionInfo() should be informative.
>
> Valerie
>
>
>
> On 08/29/2018 09:45 AM, Kasper Daniel Hansen wrote:
>
> I think the "correct" answer to this, is that it is impossible. Old
> releases are locked.
>
> The way to discover such things is to have appropriate test functions
> which will signal an error if things break.
>
> Best,
> Kasper
>
> On Tue, Aug 28, 2018 at 2:17 PM Obenchain, Valerie  roswellpark.org> wrote:
>
>> You could use an AMI with R 3.4 installed. See the 'AMI IDs' section:
>>
>> https://www.bioconductor.org/help/bioconductor-cloud-ami/#ami_ids
>>
>> Valerie
>>
>>
>> On 08/27/2018 11:48 AM, kushal kumar dey wrote:
>>
>> Hi,
>>
>> I just found based on user reports that the old version of my package
>> Logolas for R 3.4 and Bioc 3.6 is broken. It does install fine but the
>> main
>> function does not run. Everything seems to be fine however for R 3.5 and
>> Bioc 3.7. I would like to produce either an error message if someone < R
>> 3.5 tries to install Logolas, or to mend the old version. Can you please
>> let me know what is the procedure for either of these cases?
>>
>> Thanks so much.
>>
>> Kushal
>>
>>
>>
>>
>>
>> This email message may contain legally privileged and/or confidential
>> information.  If you are not the intended recipient(s), or the employee or
>> agent responsible for the delivery of this message to the intended
>> recipient(s), you are hereby notified that any disclosure, copying,
>> distribution, or use of this email message is prohibited.  If you have
>> received this message in error, please notify the sender immediately by
>> e-mail and delete this email message from your computer. Thank you.
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.



-- 
Kushal K. Dey
Graduate Student
5 th Year, Department of Statistics
University of Chicago
Contact: +1 312-709-0680 | kk...@uchicago.edu

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Joris Meys]

I have to agree with Emil here. && and || are short circuited like in C and
C++. That means that

TRUE || c(TRUE, FALSE)
FALSE && c(TRUE, FALSE)

cannot give an error because the second part is never evaluated. Throwing a
warning or error for

c(TRUE, FALSE) || TRUE

would mean that the operator gives a different result depending on the
order of the objects, breaking the symmetry. Also that would be undesirable.

Regarding logical(0): per the documentation, it is indeed so that ||, &&
and isTRUE always return a length-one logical vector. Hence the NA.

On a sidenote: there is no such thing as a scalar in R. What you call
scalar, is really a length-one vector. That seems like a detail, but is
important in understanding why this admittedly confusing behaviour actually
makes sense within the framework of R imho. I do understand your objections
and suggestions, but it would boil down to removing short circuited
operators from R.

My 2 cents.
Cheers
Joris

On Wed, Aug 29, 2018 at 5:03 AM Henrik Bengtsson 
wrote:

> # Issue
>
> 'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here
> using R 3.5.1),
>
> > c(TRUE, TRUE) || FALSE
> [1] TRUE
> > c(TRUE, FALSE) || FALSE
> [1] TRUE
> > c(TRUE, NA) || FALSE
> [1] TRUE
> > c(FALSE, TRUE) || FALSE
> [1] FALSE
>
> This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
> same) and it also applies to 'x && y'.
>
> Note also how the above truncation of 'x' is completely silent -
> there's neither an error nor a warning being produced.
>
>
> # Discussion/Suggestion
>
> Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
> mistake.  Either the code is written assuming 'x' and 'y' are scalars,
> or there is a coding error and vectorized versions 'x | y' and 'x & y'
> were intended.  Should 'x || y' always be considered an mistake if
> 'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
> or an error?  For instance,
> '''r
> > x <- c(TRUE, TRUE)
> > y <- FALSE
> > x || y
>
> Error in x || y : applying scalar operator || to non-scalar elements
> Execution halted
>
> What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today
> 'x || y' returns 'NA' in such cases, e.g.
>
> > logical(0) || c(FALSE, NA)
> [1] NA
> > logical(0) || logical(0)
> [1] NA
> > logical(0) && logical(0)
> [1] NA
>
> I don't know the background for this behavior, but I'm sure there is
> an argument behind that one.  Maybe it's simply that '||' and '&&'
> should always return a scalar logical and neither TRUE nor FALSE can
> be returned.
>
> /Henrik
>
> PS. This is in the same vein as
> https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
> - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
> _R_CHECK_LENGTH_1_CONDITION_=true
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Pushing to Bioconductor devel version...

[Shepherd, Lori]

Bioconductor assumes the master branch of a github repository is the devel 
branch.  There is no devel branch on the git.bioconductor server so you will 
have to push the changes to upstream master.  This is slightly confusing but 
stated on the git help pages


http://bioconductor.org/developers/how-to/git/



http://bioconductor.org/developers/how-to/git/push-to-github-bioc/





Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Paul Brennan 

Sent: Thursday, August 30, 2018 7:14:05 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Pushing to Bioconductor devel version...

Hi,
 Sorry but this is a new developer question but I can't find an answer
on any of the help pages.
 I have written some new function (and tests) in my package
(drawProteins) and I would like to push them onto the devel version of
Bioconductor. I have tried


git push upstream devel


but this is giving me an error message:

 ! [remote rejected] devel -> devel (hook declined)

I don't know what to do next so any guidance would be very much
appreciated.
Thanks in advance,
Paul


Paul Brennan
Cardiff University
Github: brennanpincardiff

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Pushing to Bioconductor devel version...

[Paul Brennan]

Hi,
 Sorry but this is a new developer question but I can't find an answer
on any of the help pages.
 I have written some new function (and tests) in my package
(drawProteins) and I would like to push them onto the devel version of
Bioconductor. I have tried


git push upstream devel


but this is giving me an error message:

 ! [remote rejected] devel -> devel (hook declined)

I don't know what to do next so any guidance would be very much
appreciated.
Thanks in advance,
Paul


Paul Brennan
Cardiff University
Github: brennanpincardiff

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Emil Bode]

I have to disagree, I think one of the advantages of '||' (or &&) is the lazy 
evaluation, i.e. you can use the first condition to "not care" about the second 
(and stop errors from being thrown).
So if I want to check if x is a length-one numeric with value a value between 0 
and 1, I can do 'class(x)=='numeric' && length(x)==1 && x>0 && x<1'.
In your proposal, having x=c(1,2) would throw an error or multiple warnings.
Also code that relies on the second argument not being evaluated would break, 
as we need to evaluate y in order to know length(y)
There may be some benefit in checking for length(x) only, though that could 
also cause some false positives (e.g. 'x==-1 || length(x)==0' would be a bit 
ugly, but not necessarily wrong, same for someone too lazy to write x[1] 
instead of x).

And I don’t really see the advantage. The casting to length one is (I think), a 
feature, not a bug. If I have/need a length one x, and a length one y, why not 
use '|' and '&'? I have to admit I only use them in if-statements, and if I 
need an error to be thrown when x and y are not length one, I can use the 
shorter versions and then the if throws a warning (or an error for a length-0 
or NA result).

I get it that for someone just starting in R, the differences between | and || 
can be confusing, but I guess that's just the price to pay for having a 
vectorized language.

Best regards, 
Emil Bode
 
Data-analyst
 
+31 6 43 83 89 33
emil.b...@dans.knaw.nl
 
DANS: Netherlands Institute for Permanent Access to Digital Research Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | 
i...@dans.knaw.nl  | dans.knaw.nl 

DANS is an institute of the Dutch Academy KNAW  and funding 
organisation NWO . 

On 29/08/2018, 05:03, "R-devel on behalf of Henrik Bengtsson" 
 wrote:

# Issue

'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here
using R 3.5.1),

> c(TRUE, TRUE) || FALSE
[1] TRUE
> c(TRUE, FALSE) || FALSE
[1] TRUE
> c(TRUE, NA) || FALSE
[1] TRUE
> c(FALSE, TRUE) || FALSE
[1] FALSE

This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
same) and it also applies to 'x && y'.

Note also how the above truncation of 'x' is completely silent -
there's neither an error nor a warning being produced.


# Discussion/Suggestion

Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
mistake.  Either the code is written assuming 'x' and 'y' are scalars,
or there is a coding error and vectorized versions 'x | y' and 'x & y'
were intended.  Should 'x || y' always be considered an mistake if
'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
or an error?  For instance,
'''r
> x <- c(TRUE, TRUE)
> y <- FALSE
> x || y

Error in x || y : applying scalar operator || to non-scalar elements
Execution halted

What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today
'x || y' returns 'NA' in such cases, e.g.

> logical(0) || c(FALSE, NA)
[1] NA
> logical(0) || logical(0)
[1] NA
> logical(0) && logical(0)
[1] NA

I don't know the background for this behavior, but I'm sure there is
an argument behind that one.  Maybe it's simply that '||' and '&&'
should always return a scalar logical and neither TRUE nor FALSE can
be returned.

/Henrik

PS. This is in the same vein as
https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
- in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
_R_CHECK_LENGTH_1_CONDITION_=true

__
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: [R-pkg-devel] how to fix checking S3 generic/method consistency ... WARNING

[Iñaki Ucar]

El jue., 30 ago. 2018 a las 9:02, Ulavappa Angadi
() escribió:
>
> Dear sir
>
> How to fix the below problem and details as below kindly help
>
>
> * checking S3 generic/method consistency ... WARNING
> mbferns:
>   function(x, ...)
> mbferns.default:
>   function(x, y, nf, fsize, bnum)
>
> predict:
>   function(object, ...)
> predict.mbferns:
>   function(model1, x)

There is a problem in the method signature, as highlighted above.

> See section 'Generic functions and methods' in the 'Writing R
> Extensions' manual.

And this is the relevant section of the manual, where we can read the following:

- A method must have all the arguments of the generic, including … if
the generic does.

So the dots ("...") are missing in mbferns.default and
predict.mbferns, and also "model1" should be called "object", instead,
in predict.mbferns.

Iñaki

>
> NAMESPACE as below
> xport(mbferns)
>
> S3method(predict,mbferns)
> S3method(mbferns,default)
>
> useDynLib(mbFerns,mbrfern,mbrfern_predict)
>
> import(plyr)
> import(mlbench)
>
> Functions are as below in Mulit_Branch_Ferns.R
> mbferns<-function(x,...)
>  { UseMethod("mbferns")}
>
> mbferns.default <- function(x, y, nf=2, fsize=4, bnum=4) {
> xx <- .C("mbrfern", as.double(xm), as.integer(y), as.integer(nc),
> as.integer(nr), as.integer(c),  as.integer(nf), as.integer(fsize),
> as.integer(bnum), xmin1=double(nc), xmax1=double(nc),
> flist1=integer(nf*fsize), pc=double(c), w=integer(ws))
>   model<-list(nc=xx[[3]], c=xx[[5]], nf=xx[[6]], fsize=xx[[7]],
> bnum=xx[[8]], min=xx$xmin1, max=xx$xmax1, flist=xx$flist1, w=xx$w,
> ylist=ylist, pc=xx$pc)
>
>   class(model)<-"mbferns"
>
>return(model)
> }
>
> predict.mbferns <- function(model1, x) {
>
> w1dens <- .C("mbrfern_predict", as.double(xm),  as.integer(model1$nc),
> as.integer(nr), as.integer(model1$c),  as.integer(model1$nf),
> as.integer(model1$fsize), as.integer(model1$bnum), as.double(model1$min),
> as.double(model1$max), as.integer(model1$flist), as.integer(model1$w),
> as.double(model1$pc), ye=integer(nr), prob=double(nr*model1$c) )
>
> }
> With regards
>
> Angadi U B
> Sr. Scientist
> CABin, IASRI, Pusa, New Delhi
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Iñaki Ucar

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

Re: [Rd] build package with unicode (farsi) strings

[Thierry Onkelinx]

Dear Farid,

Try using the ASCII notation. letters_fa <- c("\u0627", "\u0641"). The full
code table is available at https://www.utf8-chartable.de

Best regards,



ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey
///



2018-08-28 7:17 GMT+02:00 Faridedin Cheraghi :

> Hi,
>
> I have a R script file with Persian letters in it defined as a variable:
>
> #' @export
> letters_fa <- c('الف','ب','پ','ت','ث','ج','چ','ح','خ','ر','ز','د')
>
> I have specified the encoding field in my DESCRIPTION file of my package.
>
> ...
> Encoding: UTF-8
> ...
>
> I also included Sys.setlocale(locale="Persian") in my .RProfile, so it is
> executed when RCMD is called. However, after a BUILD and INSTALL, when I
> access the variable from the package, the characters are not printed
> correctly:
> > futils::letters_fa
>  [1] "<84><81>" "" ""
>"" ""
>  [6] "" "<86>" ""
>"" ""
> [11] "" ""
>
>
> thanks
> Farid
>
> [[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

[R-pkg-devel] how to fix checking S3 generic/method consistency ... WARNING

[Ulavappa Angadi]

Dear sir

How to fix the below problem and details as below kindly help


* checking S3 generic/method consistency ... WARNING
mbferns:
  function(x, ...)
mbferns.default:
  function(x, y, nf, fsize, bnum)

predict:
  function(object, ...)
predict.mbferns:
  function(model1, x)

See section 'Generic functions and methods' in the 'Writing R
Extensions' manual.

NAMESPACE as below
xport(mbferns)

S3method(predict,mbferns)
S3method(mbferns,default)

useDynLib(mbFerns,mbrfern,mbrfern_predict)

import(plyr)
import(mlbench)

Functions are as below in Mulit_Branch_Ferns.R
mbferns<-function(x,...)
 { UseMethod("mbferns")}

mbferns.default <- function(x, y, nf=2, fsize=4, bnum=4) {
xx <- .C("mbrfern", as.double(xm), as.integer(y), as.integer(nc),
as.integer(nr), as.integer(c),  as.integer(nf), as.integer(fsize),
as.integer(bnum), xmin1=double(nc), xmax1=double(nc),
flist1=integer(nf*fsize), pc=double(c), w=integer(ws))
  model<-list(nc=xx[[3]], c=xx[[5]], nf=xx[[6]], fsize=xx[[7]],
bnum=xx[[8]], min=xx$xmin1, max=xx$xmax1, flist=xx$flist1, w=xx$w,
ylist=ylist, pc=xx$pc)

  class(model)<-"mbferns"

   return(model)
}

predict.mbferns <- function(model1, x) {

w1dens <- .C("mbrfern_predict", as.double(xm),  as.integer(model1$nc),
as.integer(nr), as.integer(model1$c),  as.integer(model1$nf),
as.integer(model1$fsize), as.integer(model1$bnum), as.double(model1$min),
as.double(model1$max), as.integer(model1$flist), as.integer(model1$w),
as.double(model1$pc), ye=integer(nr), prob=double(nr*model1$c) )

}
With regards

Angadi U B
Sr. Scientist
CABin, IASRI, Pusa, New Delhi

[[alternative HTML version deleted]]

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

Re: [Rd] plotmath degree symbol

[Martin Møller Skarbiniks Pedersen]

On Fri, 24 Aug 2018 at 19:53, Edzer Pebesma
 wrote:
>
> In plotmath expressions, R's degree symbol, e.g. shown by
>
> plot(1, main = parse(text = "1*degree*C"))
>
> has sunk to halfway the text line, instead of touching its top. In older
> R versions this looked much better.

I can confirm this problem.

R version 3.5.1 (2018-07-02)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.1 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1

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] compiler_3.5.1

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

[Rd] build package with unicode (farsi) strings

[Faridedin Cheraghi]

Hi,

I have a R script file with Persian letters in it defined as a variable:

#' @export
letters_fa <- c('الف','ب','پ','ت','ث','ج','چ','ح','خ','ر','ز','د')

I have specified the encoding field in my DESCRIPTION file of my package.

...
Encoding: UTF-8
...

I also included Sys.setlocale(locale="Persian") in my .RProfile, so it is
executed when RCMD is called. However, after a BUILD and INSTALL, when I
access the variable from the package, the characters are not printed
correctly:
> futils::letters_fa
 [1] "<84><81>" "" ""
   "" ""
 [6] "" "<86>" ""
   "" ""
[11] "" ""


thanks
Farid

[[alternative HTML version deleted]]

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

Re: [Rd] "utils::file.edit" does not understand "editor" with additional arguments

[Prof Brian Ripley]

We do not have the 'at a minimum' information requested by the posting 
guide, and I cannot reproduce anything like this on a Unix-alike.  Both 
file.edit and edit.default call the same underlying C code, and that 
single-quotes the 'editor' argument to allow for spaces in its path/name 
so I would not expect this to work.


Two workarounds:

1) Set an alias in your shell (e.g. in .bashrc) for 'subl -n'.  This is 
something widely needed on macOS where many editors are invoked by 'open 
-a', and I also use it for 'emacsclient -n'.


2) Make use of the ability to specify editor as an R function, invoking 
the external program by system2() etc.



On 28/08/2018 20:07, Randy Lai wrote:

I am using Sublime Text as my editor. If I run `subl -n .Rprofile` in bash, a 
file would be opened in a new window.

Back in R, if I run this


file.edit(".Rprofile", editor="'subl -n'")

sh: 'subl -n': command not found
Warning message:
error in running command

However, the interesting bit happens when I run

edit(1:10, editor="'subl -n’")

It does open Sublime Text. It seems that `file.edit` and `edit` are behaving 
differently when “editor” has additional arguments.

Randy


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