Re: [Rd] segfault with POSIXlt zone=NULL zone=""

[frederik]

Thanks for the reply, Duncan.

It looks like Martin can commit a patch faster than I can open a bug
report...

Frederick

On Tue, Dec 06, 2016 at 12:39:32PM -0500, Duncan Murdoch wrote:
> I agree this is a bug; R should never segfault.  I wouldn't call it a high
> priority one, since you can avoid the problem by not messing with R's
> internal structures.
> 
> It's unlikely to get fixed unless someone posts it as a bug report to
> bugs.r-project.org (because low priority bugs reported only on mailing lists
> get forgotten).
> 
> So please post a minimal example there, possibly accompanied with a patch.
> If you don't have an account, you can write to me privately and I'll set one
> up for you.  (We no longer allow people to create their own accounts because
> of abuse by spammers.)
> 
> Duncan Murdoch

On Tue, Dec 06, 2016 at 06:49:05PM +0100, Martin Maechler wrote:
> > Joshua Ulrich 
> > on Tue, 6 Dec 2016 09:51:16 -0600 writes:
> 
> > On Tue, Dec 6, 2016 at 6:37 AM,   wrote:
> >> Hi all,
> >> 
> >> I ran into a segfault while playing with dates.
> >> 
> >> $ R --no-init-file
> >> ...
> >> > library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); 
> d$zone=NULL; d$zone=""; d
> >> 
> > If you're asking about a bug in R, you should provide a *minimal*
> > reproducible example (i.e. one without any package dependencies).
> > This has nothing to do with lubridate, so you can reproduce the
> > behavior with:
> 
> > d <- as.POSIXlt(Sys.time())
> > d$zone <- NULL
> > d$zone <- ""
> > d
> 
> [..]
> 
> >> Hope I'm not doing something illegal...
> >> 
> > You are.  You're changing the internal structure of a POSIXlt object
> > by re-ordering the list elements.  You should not expect a malformed
> > POSIXlt object to behave as if it's correctly formed.  You can see
> > it's malformed by comparing it's unclass()'d output.
> 
> > d <- as.POSIXlt(Sys.time())
> > unclass(d)  # valid POSIXlt object
> > d$zone <- NULL
> > d$zone <- ""
> > unclass(d)  # your malformed POSIXlt object
> 
> Indeed, really illegal, i.e. "against the law" ... ;-)
> 
> Thank you, Joshua!
> 
> Still, if R segfaults without the user explicitly
> calling .Call(), .Internal()  or similar -- as here --
> we usually acknowledge there *is* a bug in R .. even if it is
> only triggered by a users "illegal" messing around.
> 
> an MRE for the above, where I really only re-order the "internal" list:
> 
> d <- as.POSIXlt("2016-12-06"); dz <- d$zone; d$zone <- NULL; d$zone <- dz; f 
> <- format(d)
> 
> >  *** caught segfault ***
> > address 0x8020, cause 'memory not mapped'
> 
> > Traceback:
> >  1: format.POSIXlt(d)
> >  2: format(d)
> 
> The current code is "optimized for speed" (not perfectly), and
> a patch should hopefully address the C code.
> 
> Note that a smaller MRE -- which does *not* re-order, but just
> invalidate the time zone is
> 
>   d <- as.POSIXlt("2016-12-06"); d$zone <- 1; f <- format(d)
> 
> --
> 
> I have now committed a "minimal" patch (to the C code) which for
> the above two cases gives a sensible error rather than a
> seg.fault :
> 
>   > d <- as.POSIXlt("2016-12-06"); d$zone <- 1 ; f <- format(d)
>   Error in format.POSIXlt(d) : 
> invalid 'zone' component in "POSIXlt" structure
> 
>   > d <- as.POSIXlt("2016-12-06"); dz <- d$zone; d$zone <- NULL; d$zone <- 
> dz; f <- format(d)
>   Error in format.POSIXlt(d) : 
> invalid 'zone' component in "POSIXlt" structure
>   > 
> 
> I guess that it should still be possible to produce a segfault
> with invalid 'POSIXlt' structures though.
> 
> Martin
>

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

Re: [Rd] unlist strips date class

[Hervé Pagès]

On 12/05/2016 01:05 AM, peter dalgaard wrote:


On 02 Dec 2016, at 23:13 , Hervé Pagès  wrote:


More generally one might reasonably expect 'unlist(x)' to be equivalent
to 'do.call(c, x)' on a list 'x' where all the list elements are atomic
vectors:


Well, both are generic, and e.g. there is no "Date" method for unlist(), but 
there is for c(). It is not clear that the two should be kept in lockstep and there is 
certainly no mechanism to enforce that.


If unlist() was based on c(), or c() was based on unlist(), or
unlist() and c() were sharing more code internally, then they would
naturally be kept in lockstep and you wouldn't need any mechanism to 
enforce that.


Note that the arguments of the default S3 method for c() are:

  c(..., recursive = FALSE, use.names = TRUE)

i.e. exactly the same as unlist() (except for the default value).
This suggests that implementing one on top of the other is kind of a
natural thing to do.

H.

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Rd] segfault with POSIXlt zone=NULL zone=""

[Martin Maechler]

> Joshua Ulrich 
> on Tue, 6 Dec 2016 09:51:16 -0600 writes:

> On Tue, Dec 6, 2016 at 6:37 AM,   wrote:
>> Hi all,
>> 
>> I ran into a segfault while playing with dates.
>> 
>> $ R --no-init-file
>> ...
>> > library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); 
d$zone=NULL; d$zone=""; d
>> 
> If you're asking about a bug in R, you should provide a *minimal*
> reproducible example (i.e. one without any package dependencies).
> This has nothing to do with lubridate, so you can reproduce the
> behavior with:

> d <- as.POSIXlt(Sys.time())
> d$zone <- NULL
> d$zone <- ""
> d

[..]

>> Hope I'm not doing something illegal...
>> 
> You are.  You're changing the internal structure of a POSIXlt object
> by re-ordering the list elements.  You should not expect a malformed
> POSIXlt object to behave as if it's correctly formed.  You can see
> it's malformed by comparing it's unclass()'d output.

> d <- as.POSIXlt(Sys.time())
> unclass(d)  # valid POSIXlt object
> d$zone <- NULL
> d$zone <- ""
> unclass(d)  # your malformed POSIXlt object

Indeed, really illegal, i.e. "against the law" ... ;-)

Thank you, Joshua!

Still, if R segfaults without the user explicitly
calling .Call(), .Internal()  or similar -- as here --
we usually acknowledge there *is* a bug in R .. even if it is
only triggered by a users "illegal" messing around.

an MRE for the above, where I really only re-order the "internal" list:

d <- as.POSIXlt("2016-12-06"); dz <- d$zone; d$zone <- NULL; d$zone <- dz; f <- 
format(d)

>  *** caught segfault ***
> address 0x8020, cause 'memory not mapped'

> Traceback:
>  1: format.POSIXlt(d)
>  2: format(d)

The current code is "optimized for speed" (not perfectly), and
a patch should hopefully address the C code.

Note that a smaller MRE -- which does *not* re-order, but just
invalidate the time zone is

  d <- as.POSIXlt("2016-12-06"); d$zone <- 1; f <- format(d)

--

I have now committed a "minimal" patch (to the C code) which for
the above two cases gives a sensible error rather than a
seg.fault :

  > d <- as.POSIXlt("2016-12-06"); d$zone <- 1 ; f <- format(d)
  Error in format.POSIXlt(d) : 
invalid 'zone' component in "POSIXlt" structure

  > d <- as.POSIXlt("2016-12-06"); dz <- d$zone; d$zone <- NULL; d$zone <- dz; 
f <- format(d)
  Error in format.POSIXlt(d) : 
invalid 'zone' component in "POSIXlt" structure
  > 

I guess that it should still be possible to produce a segfault
with invalid 'POSIXlt' structures though.

Martin

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

Re: [Rd] ok to segfault with POSIXlt zone=NULL zone=""?

[Spencer Graves]

I got a similar result from R-Studio 1.0.44 with

> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X El Capitan 10.11.6

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

loaded via a namespace (and not attached):
[1] tools_3.3.2

> d <- as.POSIXlt(Sys.time())
> d$zone <- NULL
> d$zone <- ""

:  "R Session Aborted.  R encountered a fatal error.  The session was 
terminated.  Start New Session".



  I got essentially the same result with R 3.3.1.  Then I installed 
3.3.2 and got the above.



  Spencer Graves


On 12/6/2016 11:27 AM, frede...@ofb.net wrote:

Hi all,

Here's a more minimal version of my earlier bug report (thanks, Joshua
Ulrich):

d=as.POSIXlt(Sys.time()); d$zone=NULL; d$zone=""; d

I got some helpful, if glib, feedback from Joshua that the segfault
may be caused by the changing of the order of the list elements in 'd'
(representing the "internal structure" of the POSIXlt object).

He seems to think that it's OK for R to segfault - I was wondering if
someone else could lend a second opinion. My understanding is that we
should try to avoid segfaulting as a way of handling errors, if only
because they become much more difficult to debug when the R session is
forced to quit.

I don't know exactly which line is causing the bug, but looking at the
code for do_formatPOSIXlt in "src/main/datetime.c", it seems that
there would not be a huge performance penalty to add an extra sanity
check to prevent this from occurring.

Thank you,

Frederick

On Tue, Dec 06, 2016 at 04:37:20AM -0800, frede...@ofb.net wrote:

Hi all,

I ran into a segfault while playing with dates.

 $ R --no-init-file
 ...
 > library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); d$zone=NULL; 
d$zone=""; d

 Attaching package: ‘lubridate’

 The following object is masked from ‘package:base’:

 date

 Warning message:
 package ‘lubridate’ was built under R version 3.4.0

  *** caught segfault ***
 address (nil), cause 'unknown'

 Traceback:
  1: format.POSIXlt(x, usetz = TRUE)
  2: format(x, usetz = TRUE)
  3: print(format(x, usetz = TRUE), ...)
  4: print.POSIXlt(x)
  5: function (x, ...) UseMethod("print")(x)

 Possible actions:
 ...

Hope I'm not doing something illegal...

Thanks,

Frederick

__
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] ok to segfault with POSIXlt zone=NULL zone=""?

[Duncan Murdoch]

I agree this is a bug; R should never segfault.  I wouldn't call it a 
high priority one, since you can avoid the problem by not messing with 
R's internal structures.


It's unlikely to get fixed unless someone posts it as a bug report to 
bugs.r-project.org (because low priority bugs reported only on mailing 
lists get forgotten).


So please post a minimal example there, possibly accompanied with a 
patch.  If you don't have an account, you can write to me privately and 
I'll set one up for you.  (We no longer allow people to create their own 
accounts because of abuse by spammers.)


Duncan Murdoch

On 06/12/2016 12:27 PM, frede...@ofb.net wrote:

Hi all,

Here's a more minimal version of my earlier bug report (thanks, Joshua
Ulrich):

d=as.POSIXlt(Sys.time()); d$zone=NULL; d$zone=""; d

I got some helpful, if glib, feedback from Joshua that the segfault
may be caused by the changing of the order of the list elements in 'd'
(representing the "internal structure" of the POSIXlt object).

He seems to think that it's OK for R to segfault - I was wondering if
someone else could lend a second opinion. My understanding is that we
should try to avoid segfaulting as a way of handling errors, if only
because they become much more difficult to debug when the R session is
forced to quit.

I don't know exactly which line is causing the bug, but looking at the
code for do_formatPOSIXlt in "src/main/datetime.c", it seems that
there would not be a huge performance penalty to add an extra sanity
check to prevent this from occurring.

Thank you,

Frederick

On Tue, Dec 06, 2016 at 04:37:20AM -0800, frede...@ofb.net wrote:

Hi all,

I ran into a segfault while playing with dates.

$ R --no-init-file
...
> library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); d$zone=NULL; 
d$zone=""; d

Attaching package: ‘lubridate’

The following object is masked from ‘package:base’:

date

Warning message:
package ‘lubridate’ was built under R version 3.4.0

 *** caught segfault ***
address (nil), cause 'unknown'

Traceback:
 1: format.POSIXlt(x, usetz = TRUE)
 2: format(x, usetz = TRUE)
 3: print(format(x, usetz = TRUE), ...)
 4: print.POSIXlt(x)
 5: function (x, ...) UseMethod("print")(x)

Possible actions:
...

Hope I'm not doing something illegal...

Thanks,

Frederick

__
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

[Rd] ok to segfault with POSIXlt zone=NULL zone=""?

[frederik]

Hi all,

Here's a more minimal version of my earlier bug report (thanks, Joshua
Ulrich):

d=as.POSIXlt(Sys.time()); d$zone=NULL; d$zone=""; d

I got some helpful, if glib, feedback from Joshua that the segfault
may be caused by the changing of the order of the list elements in 'd'
(representing the "internal structure" of the POSIXlt object).

He seems to think that it's OK for R to segfault - I was wondering if
someone else could lend a second opinion. My understanding is that we
should try to avoid segfaulting as a way of handling errors, if only
because they become much more difficult to debug when the R session is
forced to quit.

I don't know exactly which line is causing the bug, but looking at the
code for do_formatPOSIXlt in "src/main/datetime.c", it seems that
there would not be a huge performance penalty to add an extra sanity
check to prevent this from occurring.

Thank you,

Frederick

On Tue, Dec 06, 2016 at 04:37:20AM -0800, frede...@ofb.net wrote:
> Hi all,
> 
> I ran into a segfault while playing with dates.
> 
> $ R --no-init-file
> ...
> > library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); 
> d$zone=NULL; d$zone=""; d
> 
> Attaching package: ‘lubridate’
> 
> The following object is masked from ‘package:base’:
> 
> date
> 
> Warning message:
> package ‘lubridate’ was built under R version 3.4.0 
> 
>  *** caught segfault ***
> address (nil), cause 'unknown'
> 
> Traceback:
>  1: format.POSIXlt(x, usetz = TRUE)
>  2: format(x, usetz = TRUE)
>  3: print(format(x, usetz = TRUE), ...)
>  4: print.POSIXlt(x)
>  5: function (x, ...) UseMethod("print")(x)
> 
> Possible actions:
> ...
> 
> Hope I'm not doing something illegal...
> 
> Thanks,
> 
> Frederick
> 
> __
> 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] segfault with POSIXlt zone=NULL zone=""

[Joshua Ulrich]

On Tue, Dec 6, 2016 at 10:30 AM,   wrote:
> Hi Joshua,
>
> Thank you for minimizing my test case.
>
>> > Hope I'm not doing something illegal...
>> >
>> You are.  You're changing the internal structure of a POSIXlt object
>> by re-ordering the list elements.  You should not expect a malformed
>> POSIXlt object to behave as if it's correctly formed.  You can see
>> it's malformed by comparing it's unclass()'d output.
>>
>> d <- as.POSIXlt(Sys.time())
>> unclass(d)  # valid POSIXlt object
>> d$zone <- NULL
>> d$zone <- ""
>> unclass(d)  # your malformed POSIXlt object
>
> I don't know if these questions are not already obvious, but:
>
> 1. Is there a reasonable way to fail more elegantly when a user makes
> this mistake?
>
It's not just "this mistake".  See below.

> 2. Should we update the documentation for POSIXlt to warn people that
> the optional "zone" list element must precede the optional "gmtoff"
> list element, in cases where both are present?
>
No, because that's not the only way to create a malformed POSIXlt
object. Reordering *any* of the elements results in a segfault, and
there are probably other things you could do to the internal structure
of POSIXlt objects to cause segfaults.

Maybe update the documentation to say, "If you update the internal
structure of a POSIXlt object, you deserve whatever happens."? ;-)

> Thanks,
>
> Frederick



-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com
R/Finance 2016 | www.rinfinance.com

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

Re: [Rd] Spam messages

[Marc Schwartz]

Hi,

FWIW, I checked the R-Devel subscriber list of e-mail addresses (as Co-Admin 
with Martin I have access). There are presently 1,296 subscribers to individual 
posts and 746 to post digests on R-Devel.

Neither of the two e-mail addresses referenced below as being the sources of 
spam are listed as subscribers.

A Google search of those two e-mail addresses also came up empty. The 
"octbm.com " domain is legitimate, though the web site is 
"under construction" and the whois information shows that it was registered 
earlier this year by a person in Bangladesh who seems to own a large number of 
domains:

  http://www.domainiq.com/email?mesba.ci...@gmail.com

There are a lot of technical ways of falsely generating those two e-mail 
addresses of course and an inspection of the full e-mail headers might be 
fruitful, although there are ways of manipulating those as well.

Regards,

Marc


> On Dec 6, 2016, at 10:20 AM, frede...@ofb.net wrote:
> 
> I agree that no action should be taken.
> 
> It's somewhat mystifying that the robot known as "Amy Kristen"
> responds so quickly after my post, and with such regularity (so far
> twice per hour), using perhaps several email addresses - and using the
> correct "Reply-To" headers. But more mystifying is that she keeps the
> same name the whole time. And lucky, I guess, because otherwise I
> wouldn't know how to filter her out...
> 
> On Tue, Dec 06, 2016 at 10:02:11AM -0600, Marc Schwartz wrote:
>> Hi,
>> 
>> This topic has come up previously, across the R e-mail lists and the 
>> spammers need not be subscribers (but could be), but simply reasonably 
>> competent HTML scrapers.
>> 
>> If you look at the online archives of the R lists, for example R-Devel for 
>> this month:
>> 
>>https://stat.ethz.ch/pipermail/r-devel/2016-December/thread.html 
>> 
>> 
>> and look at the individual posts, there is only minimal munging of e-mail 
>> addresses, which is easily overcome with basic scripting.
>> 
>> This is further compounded by there being a multitude of other places on the 
>> web, where actively updated archives of the R lists exist, providing 
>> additional sources of e-mail addresses for spammers.
>> 
>> Some of the prior discussions had considered that we might preserve only the 
>> list address in the posts sent out (as some groups do) and fully scrape the 
>> sender's e-mail address from the post when distributed and archived. 
>> However, that approach is not without it's own limitations (e.g. would make 
>> cc's and reply-all largely useless, except for off-list discussion) and so 
>> no action has been taken since this seems to be a transient issue.
>> 
>> Regards,
>> 
>> Marc Schwartz
>> 
>> 
>>> On Dec 6, 2016, at 7:52 AM, Mario Emmenlauer  wrote:
>>> 
>>> 
>>> The problem is not specific to this list. Any kind of public
>>> list may mean that other subscribers (or even the whole world)
>>> can see your email address. So whenever you mail to a (public)
>>> list there is a good chance that afterwards, you will get more
>>> spam. Not really much can be done about it, at least not on
>>> the side of the list, since any of the subscribers may be a
>>> spammer, who can know...
>>> 
>>> All the best,
>>> 
>>>   Mario
>>> 
>>> 
>>> 
>>> On 06.12.2016 14:13, frede...@ofb.net wrote:
 Yes, I just heard from Amy Kristen who is "looking to meet new
 guys"...
 
 On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
> Have others received spam messages after posting to this list?
> 
> The two problem emails are hodgesdonna...@yahoo.com and
> amykristen4...@octbm.com.
> 
>   [[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
 
>>> 
>>> 
>>> 
>>> Viele Gruesse,
>>> 
>>>   Mario Emmenlauer
>>> 
>>> 
>>> --
>>> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
>>> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
>>> D-81669 München  http://www.biodataanalysis.de/
>>> 
>>> __
>>> 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] segfault with POSIXlt zone=NULL zone=""

[frederik]

Hi Joshua,

Thank you for minimizing my test case.

> > Hope I'm not doing something illegal...
> >
> You are.  You're changing the internal structure of a POSIXlt object
> by re-ordering the list elements.  You should not expect a malformed
> POSIXlt object to behave as if it's correctly formed.  You can see
> it's malformed by comparing it's unclass()'d output.
> 
> d <- as.POSIXlt(Sys.time())
> unclass(d)  # valid POSIXlt object
> d$zone <- NULL
> d$zone <- ""
> unclass(d)  # your malformed POSIXlt object

I don't know if these questions are not already obvious, but:

1. Is there a reasonable way to fail more elegantly when a user makes
this mistake?

2. Should we update the documentation for POSIXlt to warn people that
the optional "zone" list element must precede the optional "gmtoff"
list element, in cases where both are present?

Thanks,

Frederick

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

Re: [Rd] Spam messages

[frederik]

I agree that no action should be taken.

It's somewhat mystifying that the robot known as "Amy Kristen"
responds so quickly after my post, and with such regularity (so far
twice per hour), using perhaps several email addresses - and using the
correct "Reply-To" headers. But more mystifying is that she keeps the
same name the whole time. And lucky, I guess, because otherwise I
wouldn't know how to filter her out...

On Tue, Dec 06, 2016 at 10:02:11AM -0600, Marc Schwartz wrote:
> Hi,
> 
> This topic has come up previously, across the R e-mail lists and the spammers 
> need not be subscribers (but could be), but simply reasonably competent HTML 
> scrapers.
> 
> If you look at the online archives of the R lists, for example R-Devel for 
> this month:
> 
> https://stat.ethz.ch/pipermail/r-devel/2016-December/thread.html 
> 
> 
> and look at the individual posts, there is only minimal munging of e-mail 
> addresses, which is easily overcome with basic scripting.
> 
> This is further compounded by there being a multitude of other places on the 
> web, where actively updated archives of the R lists exist, providing 
> additional sources of e-mail addresses for spammers.
> 
> Some of the prior discussions had considered that we might preserve only the 
> list address in the posts sent out (as some groups do) and fully scrape the 
> sender's e-mail address from the post when distributed and archived. However, 
> that approach is not without it's own limitations (e.g. would make cc's and 
> reply-all largely useless, except for off-list discussion) and so no action 
> has been taken since this seems to be a transient issue.
> 
> Regards,
> 
> Marc Schwartz
> 
> 
> > On Dec 6, 2016, at 7:52 AM, Mario Emmenlauer  wrote:
> > 
> > 
> > The problem is not specific to this list. Any kind of public
> > list may mean that other subscribers (or even the whole world)
> > can see your email address. So whenever you mail to a (public)
> > list there is a good chance that afterwards, you will get more
> > spam. Not really much can be done about it, at least not on
> > the side of the list, since any of the subscribers may be a
> > spammer, who can know...
> > 
> > All the best,
> > 
> >Mario
> > 
> > 
> > 
> > On 06.12.2016 14:13, frede...@ofb.net wrote:
> >> Yes, I just heard from Amy Kristen who is "looking to meet new
> >> guys"...
> >> 
> >> On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
> >>> Have others received spam messages after posting to this list?
> >>> 
> >>> The two problem emails are hodgesdonna...@yahoo.com and
> >>> amykristen4...@octbm.com.
> >>> 
> >>>   [[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
> >> 
> > 
> > 
> > 
> > Viele Gruesse,
> > 
> >Mario Emmenlauer
> > 
> > 
> > --
> > BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> > Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> > D-81669 München  http://www.biodataanalysis.de/
> > 
> > __
> > 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] Spam messages

[Marc Schwartz]

Hi,

This topic has come up previously, across the R e-mail lists and the spammers 
need not be subscribers (but could be), but simply reasonably competent HTML 
scrapers.

If you look at the online archives of the R lists, for example R-Devel for this 
month:

https://stat.ethz.ch/pipermail/r-devel/2016-December/thread.html 


and look at the individual posts, there is only minimal munging of e-mail 
addresses, which is easily overcome with basic scripting.

This is further compounded by there being a multitude of other places on the 
web, where actively updated archives of the R lists exist, providing additional 
sources of e-mail addresses for spammers.

Some of the prior discussions had considered that we might preserve only the 
list address in the posts sent out (as some groups do) and fully scrape the 
sender's e-mail address from the post when distributed and archived. However, 
that approach is not without it's own limitations (e.g. would make cc's and 
reply-all largely useless, except for off-list discussion) and so no action has 
been taken since this seems to be a transient issue.

Regards,

Marc Schwartz


> On Dec 6, 2016, at 7:52 AM, Mario Emmenlauer  wrote:
> 
> 
> The problem is not specific to this list. Any kind of public
> list may mean that other subscribers (or even the whole world)
> can see your email address. So whenever you mail to a (public)
> list there is a good chance that afterwards, you will get more
> spam. Not really much can be done about it, at least not on
> the side of the list, since any of the subscribers may be a
> spammer, who can know...
> 
> All the best,
> 
>Mario
> 
> 
> 
> On 06.12.2016 14:13, frede...@ofb.net wrote:
>> Yes, I just heard from Amy Kristen who is "looking to meet new
>> guys"...
>> 
>> On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
>>> Have others received spam messages after posting to this list?
>>> 
>>> The two problem emails are hodgesdonna...@yahoo.com and
>>> amykristen4...@octbm.com.
>>> 
>>> [[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
>> 
> 
> 
> 
> Viele Gruesse,
> 
>Mario Emmenlauer
> 
> 
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
> 
> __
> 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] segfault with POSIXlt zone=NULL zone=""

[Joshua Ulrich]

On Tue, Dec 6, 2016 at 6:37 AM,   wrote:
> Hi all,
>
> I ran into a segfault while playing with dates.
>
> $ R --no-init-file
> ...
> > library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); 
> d$zone=NULL; d$zone=""; d
>
If you're asking about a bug in R, you should provide a *minimal*
reproducible example (i.e. one without any package dependencies).
This has nothing to do with lubridate, so you can reproduce the
behavior with:

d <- as.POSIXlt(Sys.time())
d$zone <- NULL
d$zone <- ""
d

> Attaching package: ‘lubridate’
>
> The following object is masked from ‘package:base’:
>
> date
>
> Warning message:
> package ‘lubridate’ was built under R version 3.4.0
>
>  *** caught segfault ***
> address (nil), cause 'unknown'
>
> Traceback:
>  1: format.POSIXlt(x, usetz = TRUE)
>  2: format(x, usetz = TRUE)
>  3: print(format(x, usetz = TRUE), ...)
>  4: print.POSIXlt(x)
>  5: function (x, ...) UseMethod("print")(x)
>
> Possible actions:
> ...
>
> Hope I'm not doing something illegal...
>
You are.  You're changing the internal structure of a POSIXlt object
by re-ordering the list elements.  You should not expect a malformed
POSIXlt object to behave as if it's correctly formed.  You can see
it's malformed by comparing it's unclass()'d output.

d <- as.POSIXlt(Sys.time())
unclass(d)  # valid POSIXlt object
d$zone <- NULL
d$zone <- ""
unclass(d)  # your malformed POSIXlt object

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



-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com
R/Finance 2016 | www.rinfinance.com

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

Re: [Rd] Spam messages

[Marcelo Perlin]

Perhpas amy needs help with her new package, R_spam,which is not working
well with R_scam.  😂

Em 6 de dez de 2016 11:16,  escreveu:

Yes, I just heard from Amy Kristen who is "looking to meet new
guys"...

On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
> Have others received spam messages after posting to this list?
>
> The two problem emails are hodgesdonna...@yahoo.com and
> amykristen4...@octbm.com.
>
>   [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

[[alternative HTML version deleted]]

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

Re: [Rd] Spam messages

[Mario Emmenlauer]

The problem is not specific to this list. Any kind of public
list may mean that other subscribers (or even the whole world)
can see your email address. So whenever you mail to a (public)
list there is a good chance that afterwards, you will get more
spam. Not really much can be done about it, at least not on
the side of the list, since any of the subscribers may be a
spammer, who can know...

All the best,

Mario



On 06.12.2016 14:13, frede...@ofb.net wrote:
> Yes, I just heard from Amy Kristen who is "looking to meet new
> guys"...
> 
> On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
>> Have others received spam messages after posting to this list?
>>
>> The two problem emails are hodgesdonna...@yahoo.com and
>> amykristen4...@octbm.com.
>>
>>  [[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
> 



Viele Gruesse,

Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
D-81669 München  http://www.biodataanalysis.de/

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

[Rd] system2 fails with quiet=TRUE, but runs through with quiet=FALSE

[Johannes Rauh]

Hi,

I have recently tried to check the test coverage using library("covr") and, 
interestingly, the command

> covr::package_coverage()

fails, while

> covr::package_coverage(quiet = FALSE)

runs through without problem.  I traced the problem to a call to 
utils::install.packages(), where the option quiet is passed on.  In 
utils::install.packages(), the problem seems to lie in the following call of 
system2():

  output <- if (quiet)
FALSE else ""
  [...]
  status <- system2(cmd0, args, env = env, stdout = output,
stderr = output)

Manually changing stdout to "" makes the program run through without error (but 
then the output is there again, of course...).

The function system2 seems to be a wrapper around

  .Internal(system(command, flags, f, stdout, stderr))

In this call, if quiet = TRUE, then flags <- 21, otherwise flags <- 22.  stdout 
and stderr are passed through from system2.

I should mention that I am working with R 3.3.1 on Windows 8.

Does anyone have an idea what the flags mean and how they can make a system 
call fail?

Best
Johannes

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

Re: [Rd] Spam messages

[frederik]

> new package, R_spam

Oh, you got my hopes up!

On Tue, Dec 06, 2016 at 12:24:20PM -0200, Marcelo Perlin wrote:
> Perhpas amy needs help with her new package, R_spam,which is not working
> well with R_scam.  😂
> 
> Em 6 de dez de 2016 11:16,  escreveu:
> 
> Yes, I just heard from Amy Kristen who is "looking to meet new
> guys"...
> 
> On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
> > Have others received spam messages after posting to this list?
> >
> > The two problem emails are hodgesdonna...@yahoo.com and
> > amykristen4...@octbm.com.
> >
> >   [[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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Spam messages

[frederik]

Yes, I just heard from Amy Kristen who is "looking to meet new
guys"...

On Fri, Dec 02, 2016 at 11:31:56AM -0800, Kenny Bell wrote:
> Have others received spam messages after posting to this list?
> 
> The two problem emails are hodgesdonna...@yahoo.com and
> amykristen4...@octbm.com.
> 
>   [[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

[Rd] segfault with POSIXlt zone=NULL zone=""

[frederik]

Hi all,

I ran into a segfault while playing with dates.

$ R --no-init-file
...
> library(lubridate); d=as.POSIXlt(floor_date(Sys.time(),"year")); 
d$zone=NULL; d$zone=""; d

Attaching package: ‘lubridate’

The following object is masked from ‘package:base’:

date

Warning message:
package ‘lubridate’ was built under R version 3.4.0 

 *** caught segfault ***
address (nil), cause 'unknown'

Traceback:
 1: format.POSIXlt(x, usetz = TRUE)
 2: format(x, usetz = TRUE)
 3: print(format(x, usetz = TRUE), ...)
 4: print.POSIXlt(x)
 5: function (x, ...) UseMethod("print")(x)

Possible actions:
...

Hope I'm not doing something illegal...

Thanks,

Frederick

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