Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Ben Bolker 
  OK, you're way ahead of me.  If this is in the QA tools, I guess I
don't really see the need to change the parser and/or the language to
flag it immediately?

On Fri, Nov 20, 2020 at 7:43 PM Duncan Murdoch  wrote:
>
> On 20/11/2020 7:01 p.m., Ben Bolker wrote:
> >I may be unusual but I don't find these examples surprising at all/
> > I don't think I would make these mistakes (maybe it's easier to make
> > that mistake if you're used to a language where 'return' is a keyword
> > rather than a function?
> >
> > My two cents would be that it would make more sense to (1) write
> > code to detect these constructions in existing R code (I'm not good at
> > this, but presumably "return() as anything other than the head of an
> > element of the body of a function" would work?)
>
> No, it's commonly nested within an if() expression, and could appear
> anywhere else.
>
>   (2) apply it to some
> > corpus of R code to see whether it actually happens much;
>
> I did that, in the bug report #17180 I cited.  In 2016 it appeared to be
> misused in about 100 packages.
>
> (3) if so,
> > add the test you wrote in step 1 to the QA tools in the utils
> > package/CRAN checks.
>
> That was done this year.
>
> Duncan Murdoch
>
> >
> > On Fri, Nov 20, 2020 at 6:58 PM Henrik Bengtsson
> >  wrote:
> >>
> >> Without having dug into the details, it could be that one could update
> >> the parser by making a 'return' a keyword and require it to be
> >> followed by a parenthesis that optionally contains an expression
> >> followed by end of statement (newline or semicolon).  Such a
> >> "promotion" of the 'return' statement seems backward compatible and
> >> would end up throwing syntax errors on:
> >>
> >> function() return
> >> function() return 2*x
> >> function() return (2*x) + 1
> >>
> >> while still accepting:
> >>
> >> function() return()
> >> function() return(2*x)
> >> function() return((2*x) + 1)
> >>
> >> Just my two Friday cents
> >>
> >> /Henrik
> >>
> >> On Fri, Nov 20, 2020 at 3:37 PM Dénes Tóth  wrote:
> >>>
> >>> Yes, the behaviour of return() is absolutely consistent. I am wondering
> >>> though how many experienced R developers would predict the correct
> >>> return value just by looking at those code snippets.
> >>>
> >>> On 11/21/20 12:33 AM, Gabriel Becker wrote:
>  And the related:
> 
>   > f = function() stop(return("lol"))
> 
>   > f()
> 
>   [1] "lol"
> 
> 
>  I have a feeling all of this is just return() performing correctly
>  though. If there are already R CMD CHECK checks for this kind of thing
>  (I wasnt sure but I'm hearing from others there may be/are) that may be
>  (and/or may need to be) sufficient.
> 
>  ~G
> 
>  On Fri, Nov 20, 2020 at 3:27 PM Dénes Tóth   > wrote:
> 
>   Or even more illustratively:
> 
>   uneval_after_return <- function(x) {
>   return(x) * stop("Not evaluated")
>   }
>   uneval_after_return(1)
>   # [1] 1
> 
>   On 11/20/20 10:12 PM, Mateo Obregón wrote:
>    > Dear r-developers-
>    >
>    > After many years of using and coding in R and other languages, I
>   came across
>    > something that I think should be flagged by the parser:
>    >
>    > bug <- function (x) {
>    >   return (x + 1) * 1000
>    > }
>    >> bug(1)
>    > [1] 2
>    >
>    > The return() call is not like any other function call that
>   returns a value to
>    > the point where it was called from. I think this should
>   straightforwardly be
>    > handled in the parser by flagging it as a syntactic error.
>    >
>    > Thoughts?
>    >
>    > Mateo.
>    > --
>    > Mateo Obregón.
>    >
>    > __
>    > R-devel@r-project.org  mailing list
>    > https://stat.ethz.ch/mailman/listinfo/r-devel
>    >
> 
>   __
>   R-devel@r-project.org  mailing list
>   https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>

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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Duncan Murdoch 

On 20/11/2020 7:01 p.m., Ben Bolker wrote:

   I may be unusual but I don't find these examples surprising at all/
I don't think I would make these mistakes (maybe it's easier to make
that mistake if you're used to a language where 'return' is a keyword
rather than a function?

My two cents would be that it would make more sense to (1) write
code to detect these constructions in existing R code (I'm not good at
this, but presumably "return() as anything other than the head of an
element of the body of a function" would work?)


No, it's commonly nested within an if() expression, and could appear 
anywhere else.


 (2) apply it to some
corpus of R code to see whether it actually happens much; 


I did that, in the bug report #17180 I cited.  In 2016 it appeared to be 
misused in about 100 packages.


(3) if so,

add the test you wrote in step 1 to the QA tools in the utils
package/CRAN checks.


That was done this year.

Duncan Murdoch



On Fri, Nov 20, 2020 at 6:58 PM Henrik Bengtsson
 wrote:


Without having dug into the details, it could be that one could update
the parser by making a 'return' a keyword and require it to be
followed by a parenthesis that optionally contains an expression
followed by end of statement (newline or semicolon).  Such a
"promotion" of the 'return' statement seems backward compatible and
would end up throwing syntax errors on:

function() return
function() return 2*x
function() return (2*x) + 1

while still accepting:

function() return()
function() return(2*x)
function() return((2*x) + 1)

Just my two Friday cents

/Henrik

On Fri, Nov 20, 2020 at 3:37 PM Dénes Tóth  wrote:


Yes, the behaviour of return() is absolutely consistent. I am wondering
though how many experienced R developers would predict the correct
return value just by looking at those code snippets.

On 11/21/20 12:33 AM, Gabriel Becker wrote:

And the related:

 > f = function() stop(return("lol"))

 > f()

 [1] "lol"


I have a feeling all of this is just return() performing correctly
though. If there are already R CMD CHECK checks for this kind of thing
(I wasnt sure but I'm hearing from others there may be/are) that may be
(and/or may need to be) sufficient.

~G

On Fri, Nov 20, 2020 at 3:27 PM Dénes Tóth mailto:toth.de...@kogentum.hu>> wrote:

 Or even more illustratively:

 uneval_after_return <- function(x) {
 return(x) * stop("Not evaluated")
 }
 uneval_after_return(1)
 # [1] 1

 On 11/20/20 10:12 PM, Mateo Obregón wrote:
  > Dear r-developers-
  >
  > After many years of using and coding in R and other languages, I
 came across
  > something that I think should be flagged by the parser:
  >
  > bug <- function (x) {
  >   return (x + 1) * 1000
  > }
  >> bug(1)
  > [1] 2
  >
  > The return() call is not like any other function call that
 returns a value to
  > the point where it was called from. I think this should
 straightforwardly be
  > handled in the parser by flagging it as a syntactic error.
  >
  > Thoughts?
  >
  > Mateo.
  > --
  > Mateo Obregón.
  >
  > __
  > R-devel@r-project.org  mailing list
  > https://stat.ethz.ch/mailman/listinfo/r-devel
  >

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



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


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


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



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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Jan T. Kim via R-devel 
On Fri, Nov 20, 2020 at 02:48:11PM -0800, Bill Dunlap wrote:
> Perhaps the parser should warn if you use return() at all.  It is rarely
> needed and is akin to the evil 'GOTO' statement in that it makes the flow
> of control less obvious to the reader.

My experience is contrary to this, using return explicitly makes
code more readable for a substantial proportion of coders. This is
based on debugging return-unaware code, and helping others debug,
over many years, and finding that a considerable proportion of people
aren't very aware of the implicit return of the last evaluated
expression. Examples that I've known to cause people to despair
include code "mysteriously" going wrong after appending an "innocent"
statement like

print(x);

to a function (so the function now returns x, rather than whatever
it was returning before), or functions returning something unintended
in some rather rare combination of conditions.

>From a language design perspective it seems to me that perhaps a cause
of the problem is that return is not a keyword like "function", but a
function itself -- and, of necessity, a rather peculiar one.

Personally, I'd prefer upgrading return to a keyword, as I can't think
of any way of preventing the weirdnesses discussed in this thread while
preserving the function implementation of "return". This would also be
a step towards getting the parser to warn about uses of return that
are considered undesirable -- with the current function implementation,
the parser can't really tell whether any call will effectively be to
return, it could be anything looking as innocent as "f":

demo <- function(x, f) { message("hello"); print(f(x)); message("bye"); }
demo(3, mean);
demo(3, return);

Best regards, Jan


> -Bill
> 
> On Fri, Nov 20, 2020 at 2:37 PM Mateo Obregón 
> wrote:
> 
> > I'm not thinking of complicated cases.
> >
> > This happened to me in a function that returns 10 minute slots
> >
> > slot <- function (seconds) {
> > return (seconds %/% 600) * 600
> > }
> >
> > Obviously I found the issue while debugging and corrected my code with
> > surrounding parenthesis, but I was surprised that the R parser did not
> > catch
> > this syntactic error.
> >
> > This is especially poignant when we have to switch between languages like
> > python where the original line would produce the desired result.
> >
> > Mateo.
> > --
> > Mateo Obregón.
> >
> > On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
> > > Hi all,
> > >
> > > I can confirm this occurs for me as well.
> > >
> > > The one thing that comes to mind is that there are certain larger
> > > expressions that contain calls to return which we absolutely don't want
> > to
> > > be an error, e.g
> > >
> > > if(somestuff)
> > > return(TRUE)
> > >
> > >
> > > That said, the actual expression Mateo pointed out certainly does look
> > like
> > > an error (it definitely isn't going to do what the developer intended).
> > >
> > > I haven't looked at the parser much, to be honest. I assume there is
> > > perhaps enough differentiation of if/else that return() could be allowed
> > > within that but not inside a larger expression without it?
> > >
> > > There would be things that are legal (though horrifying) now that would
> > > stop working though, such as:
> > >
> > > f = function(a) {
> > >
> > > ret = switch(a,
> > >
> > >  "1"= return("haha got 1!"),
> > >
> > >  "2" = "regular ole 2")
> > >
> > > ret
> > >
> > > }
> > >
> > >
> > > Whether it would be a problem or not that such insanity wouldn't work is
> > > less clear. Are there valid non-if embedded return() cases that are
> > > important to allow? If so (and if they're not differentiated by the
> > parser,
> > > which I somewhat doubt switch is, for example, though I'm not certain),
> > I'm
> > > skeptical we'd be able to do as he suggests.
> > >
> > > It does seem worth considering though. If it can't be a hard parse error
> > > but we agree many/most cases are problematic, perhaps adding detecting
> > this
> > > to the static checks that R CMD CHECK performs is another way forward.
> > >
> > > Best,
> > > ~G
> > >
> > > On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 
> > >
> > > wrote:
> > > > Dear r-developers-
> > > >
> > > > After many years of using and coding in R and other languages, I came
> > > > across
> > > > something that I think should be flagged by the parser:
> > > >
> > > > bug <- function (x) {
> > > >
> > > >  return (x + 1) * 1000
> > > >
> > > > }
> > > >
> > > > > bug(1)
> > > >
> > > > [1] 2
> > > >
> > > > The return() call is not like any other function call that returns a
> > value
> > > > to
> > > > the point where it was called from. I think this should
> > straightforwardly
> > > > be
> > > > handled in the parser by flagging it as a syntactic error.
> > > >
> > > > Thoughts?
> > > >
> > > > Mateo.
> > > > --
> > > > Mateo Obregón.
> > > >
> > > >

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Duncan Murdoch 

On 20/11/2020 5:58 p.m., Mateo Obregón wrote:

I don't see how anything operating on the "result" of a return() call could be
legal. The special semantics of the return() call is that it does **not**
return control to the place it was called from, but rather to the location
where its surrounding function(){} was called from.


The problem is that in R, return() is a function.  It's a function that 
does weird things, but it's not a reserved word like it is in some other 
languages.  If you don't like the standard definition, you can change it:


return <- function() 3

f <- function() return()

f()

which will return 3.

Duncan Murdoch



Mateo.
--
Mateo Obregón.

On Friday, 20 November 2020 22:52:58 GMT Duncan Murdoch wrote:

On 20/11/2020 5:36 p.m., Mateo Obregón wrote:

I'm not thinking of complicated cases.

This happened to me in a function that returns 10 minute slots

slot <- function (seconds) {

  return (seconds %/% 600) * 600

}

Obviously I found the issue while debugging and corrected my code with
surrounding parenthesis, but I was surprised that the R parser did not
catch this syntactic error.

This is especially poignant when we have to switch between languages like
python where the original line would produce the desired result.


That's legal code, so the parser can't catch it, it needs to be caught
by some lint-like thing that looks for bad usage.  The package check
code has lots of that kind of check (including this one, though not yet
in released R).  So if you put this in a package and run the --as-cran
checks in R-devel, you'll be notified about it.

The fact that Python is different is something that's always going to
cause problems for people who are more familiar with Python.  I don't
know Python well enough to list all the gotchas, but I'm sure there are
lots of them.

Duncan Murdoch


Mateo.
--
Mateo Obregón.

On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:

Hi all,

I can confirm this occurs for me as well.

The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want
to
be an error, e.g

if(somestuff)

  return(TRUE)

That said, the actual expression Mateo pointed out certainly does look
like
an error (it definitely isn't going to do what the developer intended).

I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?

There would be things that are legal (though horrifying) now that would
stop working though, such as:

f = function(a) {

  ret = switch(a,
  
   "1"= return("haha got 1!"),
   
   "2" = "regular ole 2")
  
  ret


}


Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the
parser,
which I somewhat doubt switch is, for example, though I'm not certain),
I'm
skeptical we'd be able to do as he suggests.

It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting
this
to the static checks that R CMD CHECK performs is another way forward.

Best,
~G

On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 

wrote:

Dear r-developers-

After many years of using and coding in R and other languages, I came
across
something that I think should be flagged by the parser:

bug <- function (x) {

   return (x + 1) * 1000

}


bug(1)


[1] 2

The return() call is not like any other function call that returns a
value
to
the point where it was called from. I think this should
straightforwardly
be
handled in the parser by flagging it as a syntactic error.

Thoughts?

Mateo.
--
Mateo Obregón.

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


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






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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Ben Bolker 
  I may be unusual but I don't find these examples surprising at all/
I don't think I would make these mistakes (maybe it's easier to make
that mistake if you're used to a language where 'return' is a keyword
rather than a function?

   My two cents would be that it would make more sense to (1) write
code to detect these constructions in existing R code (I'm not good at
this, but presumably "return() as anything other than the head of an
element of the body of a function" would work?) (2) apply it to some
corpus of R code to see whether it actually happens much; (3) if so,
add the test you wrote in step 1 to the QA tools in the utils
package/CRAN checks.

On Fri, Nov 20, 2020 at 6:58 PM Henrik Bengtsson
 wrote:
>
> Without having dug into the details, it could be that one could update
> the parser by making a 'return' a keyword and require it to be
> followed by a parenthesis that optionally contains an expression
> followed by end of statement (newline or semicolon).  Such a
> "promotion" of the 'return' statement seems backward compatible and
> would end up throwing syntax errors on:
>
> function() return
> function() return 2*x
> function() return (2*x) + 1
>
> while still accepting:
>
> function() return()
> function() return(2*x)
> function() return((2*x) + 1)
>
> Just my two Friday cents
>
> /Henrik
>
> On Fri, Nov 20, 2020 at 3:37 PM Dénes Tóth  wrote:
> >
> > Yes, the behaviour of return() is absolutely consistent. I am wondering
> > though how many experienced R developers would predict the correct
> > return value just by looking at those code snippets.
> >
> > On 11/21/20 12:33 AM, Gabriel Becker wrote:
> > > And the related:
> > >
> > > > f = function() stop(return("lol"))
> > >
> > > > f()
> > >
> > > [1] "lol"
> > >
> > >
> > > I have a feeling all of this is just return() performing correctly
> > > though. If there are already R CMD CHECK checks for this kind of thing
> > > (I wasnt sure but I'm hearing from others there may be/are) that may be
> > > (and/or may need to be) sufficient.
> > >
> > > ~G
> > >
> > > On Fri, Nov 20, 2020 at 3:27 PM Dénes Tóth  > > > wrote:
> > >
> > > Or even more illustratively:
> > >
> > > uneval_after_return <- function(x) {
> > > return(x) * stop("Not evaluated")
> > > }
> > > uneval_after_return(1)
> > > # [1] 1
> > >
> > > On 11/20/20 10:12 PM, Mateo Obregón wrote:
> > >  > Dear r-developers-
> > >  >
> > >  > After many years of using and coding in R and other languages, I
> > > came across
> > >  > something that I think should be flagged by the parser:
> > >  >
> > >  > bug <- function (x) {
> > >  >   return (x + 1) * 1000
> > >  > }
> > >  >> bug(1)
> > >  > [1] 2
> > >  >
> > >  > The return() call is not like any other function call that
> > > returns a value to
> > >  > the point where it was called from. I think this should
> > > straightforwardly be
> > >  > handled in the parser by flagging it as a syntactic error.
> > >  >
> > >  > Thoughts?
> > >  >
> > >  > Mateo.
> > >  > --
> > >  > Mateo Obregón.
> > >  >
> > >  > __
> > >  > R-devel@r-project.org  mailing list
> > >  > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >  >
> > >
> > > __
> > > R-devel@r-project.org  mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> 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] return (x+1) * 1000

2020-11-20 Thread Henrik Bengtsson 
Without having dug into the details, it could be that one could update
the parser by making a 'return' a keyword and require it to be
followed by a parenthesis that optionally contains an expression
followed by end of statement (newline or semicolon).  Such a
"promotion" of the 'return' statement seems backward compatible and
would end up throwing syntax errors on:

function() return
function() return 2*x
function() return (2*x) + 1

while still accepting:

function() return()
function() return(2*x)
function() return((2*x) + 1)

Just my two Friday cents

/Henrik

On Fri, Nov 20, 2020 at 3:37 PM Dénes Tóth  wrote:
>
> Yes, the behaviour of return() is absolutely consistent. I am wondering
> though how many experienced R developers would predict the correct
> return value just by looking at those code snippets.
>
> On 11/21/20 12:33 AM, Gabriel Becker wrote:
> > And the related:
> >
> > > f = function() stop(return("lol"))
> >
> > > f()
> >
> > [1] "lol"
> >
> >
> > I have a feeling all of this is just return() performing correctly
> > though. If there are already R CMD CHECK checks for this kind of thing
> > (I wasnt sure but I'm hearing from others there may be/are) that may be
> > (and/or may need to be) sufficient.
> >
> > ~G
> >
> > On Fri, Nov 20, 2020 at 3:27 PM Dénes Tóth  > > wrote:
> >
> > Or even more illustratively:
> >
> > uneval_after_return <- function(x) {
> > return(x) * stop("Not evaluated")
> > }
> > uneval_after_return(1)
> > # [1] 1
> >
> > On 11/20/20 10:12 PM, Mateo Obregón wrote:
> >  > Dear r-developers-
> >  >
> >  > After many years of using and coding in R and other languages, I
> > came across
> >  > something that I think should be flagged by the parser:
> >  >
> >  > bug <- function (x) {
> >  >   return (x + 1) * 1000
> >  > }
> >  >> bug(1)
> >  > [1] 2
> >  >
> >  > The return() call is not like any other function call that
> > returns a value to
> >  > the point where it was called from. I think this should
> > straightforwardly be
> >  > handled in the parser by flagging it as a syntactic error.
> >  >
> >  > Thoughts?
> >  >
> >  > Mateo.
> >  > --
> >  > Mateo Obregón.
> >  >
> >  > __
> >  > R-devel@r-project.org  mailing list
> >  > https://stat.ethz.ch/mailman/listinfo/r-devel
> >  >
> >
> > __
> > R-devel@r-project.org  mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Dénes Tóth 
Yes, the behaviour of return() is absolutely consistent. I am wondering 
though how many experienced R developers would predict the correct 
return value just by looking at those code snippets.


On 11/21/20 12:33 AM, Gabriel Becker wrote:

And the related:

> f = function() stop(return("lol"))

> f()

[1] "lol"


I have a feeling all of this is just return() performing correctly 
though. If there are already R CMD CHECK checks for this kind of thing 
(I wasnt sure but I'm hearing from others there may be/are) that may be 
(and/or may need to be) sufficient.


~G

On Fri, Nov 20, 2020 at 3:27 PM Dénes Tóth > wrote:


Or even more illustratively:

uneval_after_return <- function(x) {
    return(x) * stop("Not evaluated")
}
uneval_after_return(1)
# [1] 1

On 11/20/20 10:12 PM, Mateo Obregón wrote:
 > Dear r-developers-
 >
 > After many years of using and coding in R and other languages, I
came across
 > something that I think should be flagged by the parser:
 >
 > bug <- function (x) {
 >       return (x + 1) * 1000
 > }
 >> bug(1)
 > [1] 2
 >
 > The return() call is not like any other function call that
returns a value to
 > the point where it was called from. I think this should
straightforwardly be
 > handled in the parser by flagging it as a syntactic error.
 >
 > Thoughts?
 >
 > Mateo.
 > --
 > Mateo Obregón.
 >
 > __
 > R-devel@r-project.org  mailing list
 > https://stat.ethz.ch/mailman/listinfo/r-devel
 >

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



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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Gabriel Becker 
And the related:

> f = function() stop(return("lol"))

> f()

[1] "lol"


I have a feeling all of this is just return() performing correctly though.
If there are already R CMD CHECK checks for this kind of thing (I
wasnt sure but I'm hearing from others there may be/are) that may be
(and/or may need to be) sufficient.

~G

On Fri, Nov 20, 2020 at 3:27 PM Dénes Tóth  wrote:

> Or even more illustratively:
>
> uneval_after_return <- function(x) {
>return(x) * stop("Not evaluated")
> }
> uneval_after_return(1)
> # [1] 1
>
> On 11/20/20 10:12 PM, Mateo Obregón wrote:
> > Dear r-developers-
> >
> > After many years of using and coding in R and other languages, I came
> across
> > something that I think should be flagged by the parser:
> >
> > bug <- function (x) {
> >   return (x + 1) * 1000
> > }
> >> bug(1)
> > [1] 2
> >
> > The return() call is not like any other function call that returns a
> value to
> > the point where it was called from. I think this should
> straightforwardly be
> > handled in the parser by flagging it as a syntactic error.
> >
> > Thoughts?
> >
> > Mateo.
> > --
> > Mateo Obregón.
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Dénes Tóth 

Or even more illustratively:

uneval_after_return <- function(x) {
  return(x) * stop("Not evaluated")
}
uneval_after_return(1)
# [1] 1

On 11/20/20 10:12 PM, Mateo Obregón wrote:

Dear r-developers-

After many years of using and coding in R and other languages, I came across
something that I think should be flagged by the parser:

bug <- function (x) {
  return (x + 1) * 1000
}

bug(1)

[1] 2

The return() call is not like any other function call that returns a value to
the point where it was called from. I think this should straightforwardly be
handled in the parser by flagging it as a syntactic error.

Thoughts?

Mateo.
--
Mateo Obregón.

__
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] return (x+1) * 1000

2020-11-20 Thread Mateo Obregón 
I don't see how anything operating on the "result" of a return() call could be 
legal. The special semantics of the return() call is that it does **not** 
return control to the place it was called from, but rather to the location 
where its surrounding function(){} was called from.

Mateo.
--  
Mateo Obregón.

On Friday, 20 November 2020 22:52:58 GMT Duncan Murdoch wrote:
> On 20/11/2020 5:36 p.m., Mateo Obregón wrote:
> > I'm not thinking of complicated cases.
> > 
> > This happened to me in a function that returns 10 minute slots
> > 
> > slot <- function (seconds) {
> > 
> >  return (seconds %/% 600) * 600
> > 
> > }
> > 
> > Obviously I found the issue while debugging and corrected my code with
> > surrounding parenthesis, but I was surprised that the R parser did not
> > catch this syntactic error.
> > 
> > This is especially poignant when we have to switch between languages like
> > python where the original line would produce the desired result.
> 
> That's legal code, so the parser can't catch it, it needs to be caught
> by some lint-like thing that looks for bad usage.  The package check
> code has lots of that kind of check (including this one, though not yet
> in released R).  So if you put this in a package and run the --as-cran
> checks in R-devel, you'll be notified about it.
> 
> The fact that Python is different is something that's always going to
> cause problems for people who are more familiar with Python.  I don't
> know Python well enough to list all the gotchas, but I'm sure there are
> lots of them.
> 
> Duncan Murdoch
> 
> > Mateo.
> > --
> > Mateo Obregón.
> > 
> > On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
> >> Hi all,
> >> 
> >> I can confirm this occurs for me as well.
> >> 
> >> The one thing that comes to mind is that there are certain larger
> >> expressions that contain calls to return which we absolutely don't want
> >> to
> >> be an error, e.g
> >> 
> >> if(somestuff)
> >> 
> >>  return(TRUE)
> >> 
> >> That said, the actual expression Mateo pointed out certainly does look
> >> like
> >> an error (it definitely isn't going to do what the developer intended).
> >> 
> >> I haven't looked at the parser much, to be honest. I assume there is
> >> perhaps enough differentiation of if/else that return() could be allowed
> >> within that but not inside a larger expression without it?
> >> 
> >> There would be things that are legal (though horrifying) now that would
> >> stop working though, such as:
> >> 
> >> f = function(a) {
> >> 
> >>  ret = switch(a,
> >>  
> >>   "1"= return("haha got 1!"),
> >>   
> >>   "2" = "regular ole 2")
> >>  
> >>  ret
> >> 
> >> }
> >> 
> >> 
> >> Whether it would be a problem or not that such insanity wouldn't work is
> >> less clear. Are there valid non-if embedded return() cases that are
> >> important to allow? If so (and if they're not differentiated by the
> >> parser,
> >> which I somewhat doubt switch is, for example, though I'm not certain),
> >> I'm
> >> skeptical we'd be able to do as he suggests.
> >> 
> >> It does seem worth considering though. If it can't be a hard parse error
> >> but we agree many/most cases are problematic, perhaps adding detecting
> >> this
> >> to the static checks that R CMD CHECK performs is another way forward.
> >> 
> >> Best,
> >> ~G
> >> 
> >> On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 
> >> 
> >> wrote:
> >>> Dear r-developers-
> >>> 
> >>> After many years of using and coding in R and other languages, I came
> >>> across
> >>> something that I think should be flagged by the parser:
> >>> 
> >>> bug <- function (x) {
> >>> 
> >>>   return (x + 1) * 1000
> >>> 
> >>> }
> >>> 
>  bug(1)
> >>> 
> >>> [1] 2
> >>> 
> >>> The return() call is not like any other function call that returns a
> >>> value
> >>> to
> >>> the point where it was called from. I think this should
> >>> straightforwardly
> >>> be
> >>> handled in the parser by flagging it as a syntactic error.
> >>> 
> >>> Thoughts?
> >>> 
> >>> Mateo.
> >>> --
> >>> Mateo Obregón.
> >>> 
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> > 
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Bill Dunlap 
Perhaps the parser should warn if you use return() at all.  It is rarely
needed and is akin to the evil 'GOTO' statement in that it makes the flow
of control less obvious to the reader.

-Bill

On Fri, Nov 20, 2020 at 2:37 PM Mateo Obregón 
wrote:

> I'm not thinking of complicated cases.
>
> This happened to me in a function that returns 10 minute slots
>
> slot <- function (seconds) {
> return (seconds %/% 600) * 600
> }
>
> Obviously I found the issue while debugging and corrected my code with
> surrounding parenthesis, but I was surprised that the R parser did not
> catch
> this syntactic error.
>
> This is especially poignant when we have to switch between languages like
> python where the original line would produce the desired result.
>
> Mateo.
> --
> Mateo Obregón.
>
> On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
> > Hi all,
> >
> > I can confirm this occurs for me as well.
> >
> > The one thing that comes to mind is that there are certain larger
> > expressions that contain calls to return which we absolutely don't want
> to
> > be an error, e.g
> >
> > if(somestuff)
> > return(TRUE)
> >
> >
> > That said, the actual expression Mateo pointed out certainly does look
> like
> > an error (it definitely isn't going to do what the developer intended).
> >
> > I haven't looked at the parser much, to be honest. I assume there is
> > perhaps enough differentiation of if/else that return() could be allowed
> > within that but not inside a larger expression without it?
> >
> > There would be things that are legal (though horrifying) now that would
> > stop working though, such as:
> >
> > f = function(a) {
> >
> > ret = switch(a,
> >
> >  "1"= return("haha got 1!"),
> >
> >  "2" = "regular ole 2")
> >
> > ret
> >
> > }
> >
> >
> > Whether it would be a problem or not that such insanity wouldn't work is
> > less clear. Are there valid non-if embedded return() cases that are
> > important to allow? If so (and if they're not differentiated by the
> parser,
> > which I somewhat doubt switch is, for example, though I'm not certain),
> I'm
> > skeptical we'd be able to do as he suggests.
> >
> > It does seem worth considering though. If it can't be a hard parse error
> > but we agree many/most cases are problematic, perhaps adding detecting
> this
> > to the static checks that R CMD CHECK performs is another way forward.
> >
> > Best,
> > ~G
> >
> > On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 
> >
> > wrote:
> > > Dear r-developers-
> > >
> > > After many years of using and coding in R and other languages, I came
> > > across
> > > something that I think should be flagged by the parser:
> > >
> > > bug <- function (x) {
> > >
> > >  return (x + 1) * 1000
> > >
> > > }
> > >
> > > > bug(1)
> > >
> > > [1] 2
> > >
> > > The return() call is not like any other function call that returns a
> value
> > > to
> > > the point where it was called from. I think this should
> straightforwardly
> > > be
> > > handled in the parser by flagging it as a syntactic error.
> > >
> > > Thoughts?
> > >
> > > Mateo.
> > > --
> > > Mateo Obregón.
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Duncan Murdoch 

On 20/11/2020 5:36 p.m., Mateo Obregón wrote:

I'm not thinking of complicated cases.

This happened to me in a function that returns 10 minute slots

slot <- function (seconds) {
 return (seconds %/% 600) * 600
}

Obviously I found the issue while debugging and corrected my code with
surrounding parenthesis, but I was surprised that the R parser did not catch
this syntactic error.

This is especially poignant when we have to switch between languages like
python where the original line would produce the desired result.


That's legal code, so the parser can't catch it, it needs to be caught 
by some lint-like thing that looks for bad usage.  The package check 
code has lots of that kind of check (including this one, though not yet 
in released R).  So if you put this in a package and run the --as-cran 
checks in R-devel, you'll be notified about it.


The fact that Python is different is something that's always going to 
cause problems for people who are more familiar with Python.  I don't 
know Python well enough to list all the gotchas, but I'm sure there are 
lots of them.


Duncan Murdoch



Mateo.
--
Mateo Obregón.

On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:

Hi all,

I can confirm this occurs for me as well.

The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want to
be an error, e.g

if(somestuff)
 return(TRUE)


That said, the actual expression Mateo pointed out certainly does look like
an error (it definitely isn't going to do what the developer intended).

I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?

There would be things that are legal (though horrifying) now that would
stop working though, such as:

f = function(a) {

 ret = switch(a,

  "1"= return("haha got 1!"),

  "2" = "regular ole 2")

 ret

}


Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the parser,
which I somewhat doubt switch is, for example, though I'm not certain), I'm
skeptical we'd be able to do as he suggests.

It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting this
to the static checks that R CMD CHECK performs is another way forward.

Best,
~G

On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 

wrote:

Dear r-developers-

After many years of using and coding in R and other languages, I came
across
something that I think should be flagged by the parser:

bug <- function (x) {

  return (x + 1) * 1000

}


bug(1)


[1] 2

The return() call is not like any other function call that returns a value
to
the point where it was called from. I think this should straightforwardly
be
handled in the parser by flagging it as a syntactic error.

Thoughts?

Mateo.
--
Mateo Obregón.

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


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



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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Duncan Murdoch 

On 20/11/2020 5:16 p.m., Henrik Bengtsson wrote:

FWIW, 'R CMD check --as-cran' in R-devel checks for "bogus return"
statements but I think that's only for the case when one forgets the
parentheses, e.g. 'return' instead of 'return()'.

I don't think it catches this case but I'm also not sure. Though, I can
imagine it might be possible to enhance the current check to include also
this case.

It could be that setting _R_CHECK_BOGUS_RETURN_=true will enable this check
also in earlier versions in R; not sure when it was introduced.


It's quite recent (August of this year):  see 
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17180.


Duncan Murdoch


/Henrik

On Fri, Nov 20, 2020, 13:58 Gabriel Becker  wrote:


Hi all,

I can confirm this occurs for me as well.

The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want to
be an error, e.g

if(somestuff)
 return(TRUE)


That said, the actual expression Mateo pointed out certainly does look like
an error (it definitely isn't going to do what the developer intended).

I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?

There would be things that are legal (though horrifying) now that would
stop working though, such as:

f = function(a) {

 ret = switch(a,

  "1"= return("haha got 1!"),

  "2" = "regular ole 2")

 ret

}


Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the parser,
which I somewhat doubt switch is, for example, though I'm not certain), I'm
skeptical we'd be able to do as he suggests.

It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting this
to the static checks that R CMD CHECK performs is another way forward.

Best,
~G

On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 
wrote:


Dear r-developers-

After many years of using and coding in R and other languages, I came
across
something that I think should be flagged by the parser:

bug <- function (x) {
  return (x + 1) * 1000
}

bug(1)

[1] 2

The return() call is not like any other function call that returns a

value

to
the point where it was called from. I think this should straightforwardly
be
handled in the parser by flagging it as a syntactic error.

Thoughts?

Mateo.
--
Mateo Obregón.

__
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



[[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] return (x+1) * 1000

2020-11-20 Thread Mateo Obregón 
I'm not thinking of complicated cases.

This happened to me in a function that returns 10 minute slots

slot <- function (seconds) {
return (seconds %/% 600) * 600
}

Obviously I found the issue while debugging and corrected my code with 
surrounding parenthesis, but I was surprised that the R parser did not catch 
this syntactic error.

This is especially poignant when we have to switch between languages like 
python where the original line would produce the desired result.

Mateo.
--  
Mateo Obregón.

On Friday, 20 November 2020 21:58:29 GMT Gabriel Becker wrote:
> Hi all,
> 
> I can confirm this occurs for me as well.
> 
> The one thing that comes to mind is that there are certain larger
> expressions that contain calls to return which we absolutely don't want to
> be an error, e.g
> 
> if(somestuff)
> return(TRUE)
> 
> 
> That said, the actual expression Mateo pointed out certainly does look like
> an error (it definitely isn't going to do what the developer intended).
> 
> I haven't looked at the parser much, to be honest. I assume there is
> perhaps enough differentiation of if/else that return() could be allowed
> within that but not inside a larger expression without it?
> 
> There would be things that are legal (though horrifying) now that would
> stop working though, such as:
> 
> f = function(a) {
> 
> ret = switch(a,
> 
>  "1"= return("haha got 1!"),
> 
>  "2" = "regular ole 2")
> 
> ret
> 
> }
> 
> 
> Whether it would be a problem or not that such insanity wouldn't work is
> less clear. Are there valid non-if embedded return() cases that are
> important to allow? If so (and if they're not differentiated by the parser,
> which I somewhat doubt switch is, for example, though I'm not certain), I'm
> skeptical we'd be able to do as he suggests.
> 
> It does seem worth considering though. If it can't be a hard parse error
> but we agree many/most cases are problematic, perhaps adding detecting this
> to the static checks that R CMD CHECK performs is another way forward.
> 
> Best,
> ~G
> 
> On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 
> 
> wrote:
> > Dear r-developers-
> > 
> > After many years of using and coding in R and other languages, I came
> > across
> > something that I think should be flagged by the parser:
> > 
> > bug <- function (x) {
> > 
> >  return (x + 1) * 1000
> > 
> > }
> > 
> > > bug(1)
> > 
> > [1] 2
> > 
> > The return() call is not like any other function call that returns a value
> > to
> > the point where it was called from. I think this should straightforwardly
> > be
> > handled in the parser by flagging it as a syntactic error.
> > 
> > Thoughts?
> > 
> > Mateo.
> > --
> > Mateo Obregón.
> > 
> > __
> > 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] return (x+1) * 1000

2020-11-20 Thread Henrik Bengtsson 
FWIW, 'R CMD check --as-cran' in R-devel checks for "bogus return"
statements but I think that's only for the case when one forgets the
parentheses, e.g. 'return' instead of 'return()'.

I don't think it catches this case but I'm also not sure. Though, I can
imagine it might be possible to enhance the current check to include also
this case.

It could be that setting _R_CHECK_BOGUS_RETURN_=true will enable this check
also in earlier versions in R; not sure when it was introduced.

/Henrik

On Fri, Nov 20, 2020, 13:58 Gabriel Becker  wrote:

> Hi all,
>
> I can confirm this occurs for me as well.
>
> The one thing that comes to mind is that there are certain larger
> expressions that contain calls to return which we absolutely don't want to
> be an error, e.g
>
> if(somestuff)
> return(TRUE)
>
>
> That said, the actual expression Mateo pointed out certainly does look like
> an error (it definitely isn't going to do what the developer intended).
>
> I haven't looked at the parser much, to be honest. I assume there is
> perhaps enough differentiation of if/else that return() could be allowed
> within that but not inside a larger expression without it?
>
> There would be things that are legal (though horrifying) now that would
> stop working though, such as:
>
> f = function(a) {
>
> ret = switch(a,
>
>  "1"= return("haha got 1!"),
>
>  "2" = "regular ole 2")
>
> ret
>
> }
>
>
> Whether it would be a problem or not that such insanity wouldn't work is
> less clear. Are there valid non-if embedded return() cases that are
> important to allow? If so (and if they're not differentiated by the parser,
> which I somewhat doubt switch is, for example, though I'm not certain), I'm
> skeptical we'd be able to do as he suggests.
>
> It does seem worth considering though. If it can't be a hard parse error
> but we agree many/most cases are problematic, perhaps adding detecting this
> to the static checks that R CMD CHECK performs is another way forward.
>
> Best,
> ~G
>
> On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 
> wrote:
>
> > Dear r-developers-
> >
> > After many years of using and coding in R and other languages, I came
> > across
> > something that I think should be flagged by the parser:
> >
> > bug <- function (x) {
> >  return (x + 1) * 1000
> > }
> > > bug(1)
> > [1] 2
> >
> > The return() call is not like any other function call that returns a
> value
> > to
> > the point where it was called from. I think this should straightforwardly
> > be
> > handled in the parser by flagging it as a syntactic error.
> >
> > Thoughts?
> >
> > Mateo.
> > --
> > Mateo Obregón.
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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

Re: [Rd] return (x+1) * 1000

2020-11-20 Thread Gabriel Becker 
Hi all,

I can confirm this occurs for me as well.

The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want to
be an error, e.g

if(somestuff)
return(TRUE)


That said, the actual expression Mateo pointed out certainly does look like
an error (it definitely isn't going to do what the developer intended).

I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?

There would be things that are legal (though horrifying) now that would
stop working though, such as:

f = function(a) {

ret = switch(a,

 "1"= return("haha got 1!"),

 "2" = "regular ole 2")

ret

}


Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the parser,
which I somewhat doubt switch is, for example, though I'm not certain), I'm
skeptical we'd be able to do as he suggests.

It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting this
to the static checks that R CMD CHECK performs is another way forward.

Best,
~G

On Fri, Nov 20, 2020 at 1:34 PM Mateo Obregón 
wrote:

> Dear r-developers-
>
> After many years of using and coding in R and other languages, I came
> across
> something that I think should be flagged by the parser:
>
> bug <- function (x) {
>  return (x + 1) * 1000
> }
> > bug(1)
> [1] 2
>
> The return() call is not like any other function call that returns a value
> to
> the point where it was called from. I think this should straightforwardly
> be
> handled in the parser by flagging it as a syntactic error.
>
> Thoughts?
>
> Mateo.
> --
> Mateo Obregón.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

[Rd] return (x+1) * 1000

2020-11-20 Thread Mateo Obregón 
Dear r-developers-

After many years of using and coding in R and other languages, I came across 
something that I think should be flagged by the parser:

bug <- function (x) {
 return (x + 1) * 1000
}
> bug(1)
[1] 2

The return() call is not like any other function call that returns a value to 
the point where it was called from. I think this should straightforwardly be 
handled in the parser by flagging it as a syntactic error.

Thoughts?

Mateo.
--  
Mateo Obregón.

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

Re: [Bioc-devel] [EXT] Re: Maintainer change request -Phenogenranker

2020-11-20 Thread Bozdag, Serdar 
Thank you so much.

Serdar

On Nov 20, 2020, at 8:21 AM, Kern, Lori  wrote:


I will take care of this shortly and post on the issue when it is resolved.

Thank you.


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Bozdag, Serdar 

Sent: Thursday, November 19, 2020 11:15 PM
To: bioc-devel@r-project.org 
Cc: Cagatay Dursun ; cagataydur...@gmail.com 

Subject: [Bioc-devel] Maintainer change request -Phenogenranker

Hi

I�m writing to request a maintainer contact change for the PhenoGeneRanker 
package that we submitted to Bioconductor 
(https://secure-web.cisco.com/1hiYp-Uwd-YtCuCicuCpgXu3xhwEbLzaLRB39H64bAMdwJ-4DSWPn0BafdJVWv6gU-jMRy1rPNucvFHm-W43gXiqEV0fMceoJ1wQCm2n7fWnAkDT660qlK9ITs5Gc9MOt6SalRpFCAN7x2cNlTyz-dNwSXkOF5FwBbrRZi3L-fvyq1vsUp07h-Neq2cMEsrGgV-5LwwrPKAdTapP6SYBJsjI-4yGrA-QfAmuLK5bDI2NQQWSgOlF3Hzt4xfqPLP9jX1fU7cEK7tGKeeZ1WRBk-2fUYwqKqAlRu526YY1w1UQ7iqoy72t3a5EKd8tc-LMo/https%3A%2F%2Fgithub.com%2FBioconductor%2FContributions%2Fissues%2F1576).

This package was developed in my lab ( 
https://secure-web.cisco.com/1fUvlcQ2JiNbT-ZP1b-fyoNMblbz2SCB-b_cyoKG2x0OQ0QTraUI3FkRwSjpZhbQrK8NYT9oSQosJ80p1F0LW1CyloXv5FEo_d5sj3SuMTn74mXPKFoQXAneh9lGENildT4bYps_msA6_2D8Wf1BZXjHiPwuS_qsFrAgy14N7FIOFEu9UuU7rukbcFPPu-QevrLqDxyID6saeDMlFSJaJD0-Ub65ShWVAWcJQ7HAiuvQnBQGdsNOPZJ5rOBDpJ0RiLTfHqsLhSzNdlM-OkQC2Nb48zvvtUH0-P0FTTk9_qSVtIw5Lx1Eq1iAoLU3KnTWa/https%3A%2F%2Fgithub.com%2Fbozdaglab%2FPhenoGeneRanker)
 and was initially submitted to Bioconductor by Jake Petrie, my former 
undergraduate RA. Jake is no longer in this project and my PhD student Cagatay 
Dursun will take care of the future submissions requested by the reviewer.

I�d like to request that the maintainer of the package is changed to 
cagataydur...@gmail.com .

Please let me know if you need any additioanal information for this request.

Thanks,


Serdar Bozdag, Ph.D.
Associate Professor of Computer Science
Dept. of Computer Science and Engineering
Dept. of Mathematics
BioDiscovery Institute

Discovery Park F295
University of North Texas
Denton, TX 76203-5017
Web: 
https://secure-web.cisco.com/1XJyYyEiEvbGJUEyi9-M0GjLtFAyRIepJhFL6cvgoA6WmfPHt9QYK84V3lVfkfWUKJqNG01doNqkRK4hNMMdSn1kV_Cu-qEN5bve-sDzIyFP5Qc1fa6rj6CEGrBnPS48ImR7Pqu2WrW7SRMSPbL1AHMkeFpgJpki6HJr4AEFyAFJ9XbApP4bNAgT8pmlsOc943rqBMoD-0ZcEGFIgTgHC-sBO6XnYaedBnmf-tgJqa0jZngvAHIGy_6tgwqqrQ1wv_wpioPHJcfNOS0B3msIyrk-sNQu6-n3cpRrRbopDG0SHw7gniASbVA-3xfKSMyc5/https%3A%2F%2Fbiocomp.engineering.unt.edu%2F
Twitter:

Re: [Bioc-devel] Maintainer change request -Phenogenranker

2020-11-20 Thread Kern, Lori 
I will take care of this shortly and post on the issue when it is resolved.

Thank you.


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Bozdag, Serdar 

Sent: Thursday, November 19, 2020 11:15 PM
To: bioc-devel@r-project.org 
Cc: Cagatay Dursun ; cagataydur...@gmail.com 

Subject: [Bioc-devel] Maintainer change request -Phenogenranker

Hi

I�m writing to request a maintainer contact change for the PhenoGeneRanker 
package that we submitted to Bioconductor 
(https://secure-web.cisco.com/1hiYp-Uwd-YtCuCicuCpgXu3xhwEbLzaLRB39H64bAMdwJ-4DSWPn0BafdJVWv6gU-jMRy1rPNucvFHm-W43gXiqEV0fMceoJ1wQCm2n7fWnAkDT660qlK9ITs5Gc9MOt6SalRpFCAN7x2cNlTyz-dNwSXkOF5FwBbrRZi3L-fvyq1vsUp07h-Neq2cMEsrGgV-5LwwrPKAdTapP6SYBJsjI-4yGrA-QfAmuLK5bDI2NQQWSgOlF3Hzt4xfqPLP9jX1fU7cEK7tGKeeZ1WRBk-2fUYwqKqAlRu526YY1w1UQ7iqoy72t3a5EKd8tc-LMo/https%3A%2F%2Fgithub.com%2FBioconductor%2FContributions%2Fissues%2F1576).

This package was developed in my lab ( 
https://secure-web.cisco.com/1fUvlcQ2JiNbT-ZP1b-fyoNMblbz2SCB-b_cyoKG2x0OQ0QTraUI3FkRwSjpZhbQrK8NYT9oSQosJ80p1F0LW1CyloXv5FEo_d5sj3SuMTn74mXPKFoQXAneh9lGENildT4bYps_msA6_2D8Wf1BZXjHiPwuS_qsFrAgy14N7FIOFEu9UuU7rukbcFPPu-QevrLqDxyID6saeDMlFSJaJD0-Ub65ShWVAWcJQ7HAiuvQnBQGdsNOPZJ5rOBDpJ0RiLTfHqsLhSzNdlM-OkQC2Nb48zvvtUH0-P0FTTk9_qSVtIw5Lx1Eq1iAoLU3KnTWa/https%3A%2F%2Fgithub.com%2Fbozdaglab%2FPhenoGeneRanker)
 and was initially submitted to Bioconductor by Jake Petrie, my former 
undergraduate RA. Jake is no longer in this project and my PhD student Cagatay 
Dursun will take care of the future submissions requested by the reviewer.

I�d like to request that the maintainer of the package is changed to 
cagataydur...@gmail.com .

Please let me know if you need any additioanal information for this request.

Thanks,


Serdar Bozdag, Ph.D.
Associate Professor of Computer Science
Dept. of Computer Science and Engineering
Dept. of Mathematics
BioDiscovery Institute

Discovery Park F295
University of North Texas
Denton, TX 76203-5017
Web: 
https://secure-web.cisco.com/1XJyYyEiEvbGJUEyi9-M0GjLtFAyRIepJhFL6cvgoA6WmfPHt9QYK84V3lVfkfWUKJqNG01doNqkRK4hNMMdSn1kV_Cu-qEN5bve-sDzIyFP5Qc1fa6rj6CEGrBnPS48ImR7Pqu2WrW7SRMSPbL1AHMkeFpgJpki6HJr4AEFyAFJ9XbApP4bNAgT8pmlsOc943rqBMoD-0ZcEGFIgTgHC-sBO6XnYaedBnmf-tgJqa0jZngvAHIGy_6tgwqqrQ1wv_wpioPHJcfNOS0B3msIyrk-sNQu6-n3cpRrRbopDG0SHw7gniASbVA-3xfKSMyc5/https%3A%2F%2Fbiocomp.engineering.unt.edu%2F
Twitter: 
@bozdags




[[alternative HTML version deleted]]



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] Maintainer change request -Phenogenranker

2020-11-20 Thread Bozdag, Serdar 
Hi

I�m writing to request a maintainer contact change for the PhenoGeneRanker 
package that we submitted to Bioconductor 
(https://github.com/Bioconductor/Contributions/issues/1576).

This package was developed in my lab ( 
https://github.com/bozdaglab/PhenoGeneRanker) and was initially submitted to 
Bioconductor by Jake Petrie, my former undergraduate RA. Jake is no longer in 
this project and my PhD student Cagatay Dursun will take care of the future 
submissions requested by the reviewer.

I�d like to request that the maintainer of the package is changed to 
cagataydur...@gmail.com .

Please let me know if you need any additioanal information for this request.

Thanks,


Serdar Bozdag, Ph.D.
Associate Professor of Computer Science
Dept. of Computer Science and Engineering
Dept. of Mathematics
BioDiscovery Institute

Discovery Park F295
University of North Texas
Denton, TX 76203-5017
Web: https://biocomp.engineering.unt.edu/
Twitter: @bozdags




[[alternative HTML version deleted]]

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

[Bioc-devel] Switch to rJava - "buffer overflow detected" error

2020-11-20 Thread Shraddha Pai 
Hello BioC community,
Our package netDx makes Java calls; to support Win machines and various
Java flavours I recently switched from system2() java calls to rJava.

Now my vignettes crash with a "buffer overflow detected" error, followed by
a core dump. Error below this email

I don't think it's a memory issue because in my zzz.R file I'm assigning
10Gb to Java heap space.

I would appreciate any insights to help debug the issue.All these vignettes
were working on OS X and Unix machines, with the previous system2("java")
call.

This is with netDx v1.3.1 which is in Bioc-devel release.

Thanks,Shraddha
--
Shraddha Pai, PhD
http://shraddhapai.com ; @spaiglass on Twitter
Post-doctoral Fellow, http://baderlab.org
The Donnelly Centre for Cellular and Biomolecular Research
University of Toronto
---
On bioc-devel Docker:

$ R CMD build netDx

[Thread 1] Finished
/tmp/RtmpbD9vyG/HWTSC5751L/ASD/part3/GM_results/CV_2.query
[Thread 1] Processing
/tmp/RtmpbD9vyG/HWTSC5751L/ASD/part3/GM_results/CV_3.query...
finished computation - writing results
[Thread 1] Finished
/tmp/RtmpbD9vyG/HWTSC5751L/ASD/part3/GM_results/CV_3.query
Performed 3 predictions in 2.90s
--- finished re-building 'Predict_CaseControl_from_CNV.Rmd'

--- re-building 'ThreeWayClassifier.Rmd' using knitr
*** buffer overflow detected ***: terminated

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] View package posts from its web page

2020-11-20 Thread Kern, Lori 
Thank you for letting us know.  We have recently updated the support site;  I 
will check the end point API behind the link and make the necessary changes.

I have opened a github issue for the website to keep track of this issue.
https://github.com/Bioconductor/bioconductor.org/issues/77

Cheers


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Stefano de 
Pretis 
Sent: Friday, November 20, 2020 5:02 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] View package posts from its web page

Hi Bioconductor team,

I noticed that the posts present in the Bioconductor Forum associated with
each Bioc package are not accessible from the package website itself.
Taking the popular DESeq2 package as an example, if you click on the
"posts" tag within the package webpage, the browser attempts to open the
website:

 
https://secure-web.cisco.com/18Y-vvj1gCy87nlObZy3jVR8K1deqMwBVqj-CuuxuIRzYnBUtBY0DeCuSpSjtRt24IHQSVLfXgA8gMo1CFtBOOD6wb_SboNxb8g09gcXsUvUvE5Hj5QBobY3keQj2G9oMDd_JCzcB8ejWh7t8jBTRUPWrCezKf_aS_-JrInaBihsi7M-bjphwe3SMapVzENxhrJ1aYekGc3CxnnNTeL18KbltdpVteTX46uk-1Sa_hMGokVU4cdZtyvtAKGFbZSuPvJWTcbBkvCY6Gcm_WoX8ofQM3qyKnOBECWiP04HUzPWrBf7NH-r8vx7s9smb89t2KUNAZHJTyWLK9doicNWfpA/https%3A%2F%2Fsupport.bioconductor.org%2Ft%2Fdeseq2%2F

throwing back an error. I guess that page:

https://secure-web.cisco.com/1vr1YOlrBjB4Iz1HQG_Mm0Xia_b_pfcWggpKdtfOHNWNw9OTP4qsvI9sy38UgaSSSs4AOozGN0gPUPNUGVmiWK9cED6MzsP7YwODeC3NzWmgA4rFMriCopaq2BdjltHBHZXBzdAVRG7eORCofZAj7VyeyjHPFeWBGptBoxJBpO6CR5T2Ju95RAiOzOI0QkkDvYx-pEzZtJ38RqVoLCMgqrXp7X9FnLuY81zLBTl08ISN3UxeCDIH2Cag28hOwvrSDnm-GnCF8w9h-tWw8eWzQ7Zc2iwchOtEw7ifEe1izk8yDQYe9K7A-wrUkHsCB8SQ_6TVJkTneYZtca8seD8BoRQ/https%3A%2F%2Fsupport.bioconductor.org%2F%3Ftag%3DDESeq2

should be opened instead.

Best regards,
Stefano

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1R6svmHDBBniUqMOHEeYD1SHCKu_W5TV3x_A69dcyfTNSi-vvcDH1x6p6nZ2_wpNP-pjrFAlvCCe0fLmtYyOXZJpOHIEURvwHSzwxni08xfWsmVOjn0upCqOLg0LZWxS4cISJWZUBp6R1FnhWcUjE7WfGC-710ZxKtgOVOUG9ciDRrnCAa-SWLoepOsMLvt0645azPNp2RJahMFklNmIP4dik-W7y4FTVAIC3p__t6EpoYMuOnKOwZy0ai0cIsY_Miu6qhCw5FbZjnFyrOwckL1jJ-Z62zFy6eMEkPoCjR5P0g0GKX3zhTbZ5kqlIIGEcpGS1Q2sAwubDCw_dAhNK-w/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-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] View package posts from its web page

2020-11-20 Thread Stefano de Pretis 
Hi Bioconductor team,

I noticed that the posts present in the Bioconductor Forum associated with
each Bioc package are not accessible from the package website itself.
Taking the popular DESeq2 package as an example, if you click on the
"posts" tag within the package webpage, the browser attempts to open the
website:

 https://support.bioconductor.org/t/deseq2/

throwing back an error. I guess that page:

https://support.bioconductor.org/?tag=DESeq2

should be opened instead.

Best regards,
Stefano

[[alternative HTML version deleted]]

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