Re: [Rd] problem submitting R bug; bug plotting in tiling window manager

2016-02-07 Thread peter dalgaard
Unfortunately, the spammers in question appear to be human (of sorts). 

We're not sure what they're up to, but a common pattern is to post random text, 
or something copied from a generic bug report (like "able to add 6 item"), 
later followed by a comment containing a link or a file attachment. 

Presumably, it is some sort of click-bait scheme, but it could also be a covert 
channel for contrabande files. At any rate, it is very hard to distinguish by 
mechanical means. So it is done by eye, with some risk of Type-I error. Thus, 
the Bugzilla maintainers are pretty vigilant to stamp out spammers, sometimes 
edging on being ham-fisted (er, -footed?).

-pd


> On 07 Feb 2016, at 00:25 , frede...@ofb.net wrote:
> 
> No problem.
> 
> Another suggestion would be to simply validate user input like most
> websites, and reject invalid submissions immediately, rather than
> blocking the user's account. I don't know what kind of spambots you
> are up against, but unless they are very intelligent I doubt they'll
> be able to understand a message like "You submitted a bug with no body
> text, please enter something and try again." There may also be the
> option of using Captchas.
> 
> Not sure how hard it is to get Bugzilla to do these things.
> 
> Thanks,
> 
> Frederick
> 
> P.S. (I now see that all errors on the bug tracker are displayed with
> a red background)
> 
> On Sat, Feb 06, 2016 at 03:00:21AM -0500, Duncan Murdoch wrote:
>> Thanks for the suggestions.
>> 
>> Duncan Murdoch
>> 
>> On 05/02/2016 10:07 PM, frede...@ofb.net wrote:
>>> Hi Duncan Murdoch,
>>> 
>>> Thanks for your time. I apologize for not telling you that my email
>>> address on the bug tracker is slightly different -
>>> "frederik-rproj...@ofb.net" vs "frede...@ofb.net". I was going to
>>> follow up with this information, but then I thought, he probably knows
>>> how to find a tagged email address.
>>> 
>>> I do hope that you are able to fix the bug tracker. In particular,
>>> people should be made aware that their account is blocked before being
>>> invited to submit a bug. The error they get should be less rude - no
>>> need to make it red - and the email address in the error should be
>>> filled in. You complained about wasting time having to look for my
>>> email address - well, I wasted time looking for yours. The error
>>> message could even hint at what triggered the ban. I don't think that
>>> you're going to get very far by trying to scare off actual spammers
>>> with a big red accusation - I imagine they all have pretty thick skin.
>>> 
>>> Reading the first line of my bug report was generous of you, but if
>>> you read the rest, you'll see that, indeed, after checking with the
>>> knowledgeable i3 guys, it appears to be an R bug. So I would like to
>>> submit it. What appears at the top of my bug report is a copy of the
>>> original bug I posted to i3, at the linked URL (are links OK or will I
>>> get banned again?).
>>> 
>>> The reason a bug appeared with the subject "til" is because I noticed
>>> that when typing into the subject field, some "related bugs" come up.
>>> However, this "suggestion" process appeared to be stalled when I typed
>>> "til" (for "tiling" or "tilable"). I tried hitting "enter" and it
>>> ended up opening a bug with that subject, which I never submitted,
>>> because I clicked "back" and figured out that *four* characters are
>>> actually necesary to start getting suggestions. The whole point of
>>> doing this was to see if another bug had been submitted with the same
>>> topic, and thereby save you time! I'm not going to try to reproduce
>>> this error, because you said it will get me banned again, but I think
>>> somebody should try to fix the site so that people don't get banned
>>> for any content which is not submitted. Especially people with
>>> months-old accounts, like me.
>>> 
>>> I definitely sympathize with the spam problem, and thank you for your
>>> hard work. Best wishes,
>>> 
>>> Frederick
>>> 
>>> On Fri, Feb 05, 2016 at 08:19:40PM -0500, Duncan Murdoch wrote:
 On 05/02/2016 7:26 PM, frede...@ofb.net wrote:
> Dear Dirk Eddelbuettel and Duncan Murdoch,
> 
> Thank you for your work on the wonderful R project!
> 
> I recently attempted to submit a bug with your Bugzilla interface:
> 
> https://bugs.r-project.org/bugzilla/enter_bug.cgi
> 
> I created an account, typed in all my information, first checking
> details with another project. Then I clicked submit, and was taken to
> a web page with a big red banner, it said
> 
>   Spammer
>   If you believe your account should be restored, please send email to 
> explaining why.
> 
> What a hostile thing to say to your users! I tried resubmitting my
> bug, but removing any links, and I still get the message - so it looks
> like my account has really been blocked. Please do something to warn
> your users about this so they can avoid the upset.
 
 Your account is

[Rd] Assignment in environment

2016-02-07 Thread Daniel Kaschek

Dear all,

I have a function "fn" with its own environment, i.e.

env <- environment(fn)

and env is not .GlobalEnv. And another function

getValue <- function(x) environment(x)$mylist

which returns the list object "mylist" which is in "env". If I want to 
modify "mylist", I could write


'getValue<-' <- function(x, value) { environment(x)$mylist <- value}

which gives not the desired result, e.g.

getValue(fn)[[1]] <- 3

will set the first list entry of "mylist" to 3. But then "fn" will also 
be 3!


environment(fn)$mylist[[1]] <- 3

does set the list entry correctly while keeping "fn". What's the 
difference?


Cheers,
Daniel

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


Re: [Rd] Assignment in environment

2016-02-07 Thread Duncan Murdoch

On 07/02/2016 8:08 AM, Daniel Kaschek wrote:

Dear all,

I have a function "fn" with its own environment, i.e.

env <- environment(fn)

and env is not .GlobalEnv. And another function

getValue <- function(x) environment(x)$mylist

which returns the list object "mylist" which is in "env". If I want to
modify "mylist", I could write

'getValue<-' <- function(x, value) { environment(x)$mylist <- value}

which gives not the desired result, e.g.

getValue(fn)[[1]] <- 3

will set the first list entry of "mylist" to 3. But then "fn" will also
be 3!

environment(fn)$mylist[[1]] <- 3

does set the list entry correctly while keeping "fn". What's the
difference?


An assignment function should return the modified value.  So it looks 
like you would need



'getValue<-' <- function(x, value) {
   environment(x)$mylist <- value
   x
 }

but in fact, this doesn't work:

getValue(fn)[[1]] <- 3
Error in getValue(fn)[[1]] <- 3 : could not find function "getValue"

I suspect this is a parser problem.  However, it does suggest a simple 
workaround for you:


Just define

getValue <- function(x) environment(x)$mylist

and then your expression works as expected.

Duncan Murdoch

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


Re: [Rd] Assignment in environment

2016-02-07 Thread peter dalgaard

> On 07 Feb 2016, at 14:46 , Duncan Murdoch  wrot8[e:
> 
[snippage]
> 
> but in fact, this doesn't work:
> 
> getValue(fn)[[1]] <- 3
> Error in getValue(fn)[[1]] <- 3 : could not find function "getValue"
> 
> I suspect this is a parser problem.

Umm, no...

The canonical semantics are that 

foo(x)[[]] <- bar

is internally converted to

*tmp* <- foo(x)
*tmp*[[]] <- bar
x <- `foo<-`(x, *tmp*)

so both foo() and `foo<-` are required.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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


Re: [Rd] Assignment in environment

2016-02-07 Thread Daniel Kaschek
On So, Feb 7, 2016 at 2:46 , Duncan Murdoch  
wrote:


An assignment function should return the modified value.  So it looks 
like you would need



'getValue<-' <- function(x, value) {
   environment(x)$mylist <- value
   x
 }


Thanks. I have not thought of a return value. That makes the difference.




but in fact, this doesn't work:

getValue(fn)[[1]] <- 3
Error in getValue(fn)[[1]] <- 3 : could not find function "getValue"



I have a "getValue" function anyway. It was even the other way round. I 
wanted to assign values without a function "getValue<-" and was rebuked 
by R that this function was missing.


Thanks to both of you, Peter and Duncan.

Best regards,
Daniel

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


Re: [Rd] Assignment in environment

2016-02-07 Thread Duncan Murdoch

On 07/02/2016 9:15 AM, peter dalgaard wrote:



On 07 Feb 2016, at 14:46 , Duncan Murdoch  wrot8[e:


[snippage]


but in fact, this doesn't work:

getValue(fn)[[1]] <- 3
Error in getValue(fn)[[1]] <- 3 : could not find function "getValue"

I suspect this is a parser problem.


Umm, no...

The canonical semantics are that

foo(x)[[]] <- bar

is internally converted to

*tmp* <- foo(x)
*tmp*[[]] <- bar
x <- `foo<-`(x, *tmp*)

so both foo() and `foo<-` are required.



Yes, you're right.  I need more sleep.

Duncan Murdoch

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