Re: [Bioc-devel] [Bioc-degel] AnnotationHub needed in the description of the ExperimentHubData

[Obenchain, Valerie]

Yes, changes are in ExperimentHubData 1.1.4 and ExperimentHub 1.1.2 as
stated below.

The change was made after the builds picked up yesterday so the new
version should propagate to the landing page tomorrow (Wed Dec 7) or you
can get them immediately from svn with

svn co
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/ExperimentHub
svn co
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/ExperimentHubData

Valerie


On 12/06/2016 10:38 AM, Marcin Kosiński wrote:
> Hi Valerie,
>
> Thanks for looking around.
> Have you provided this changes to the vignette?
> In
> https://bioconductor.org/packages/devel/bioc/vignettes/ExperimentHubData/inst/doc/ExperimentHubData.html#bug-fixes
> devel there looks to be a code appearance issue in chapter
>
>
> 2.2 Building the software package -> documentation data loading
>
> check release vignette
> https://bioconductor.org/packages/release/bioc/vignettes/ExperimentHubData/inst/doc/ExperimentHubData.html
>
>
> 2016-12-05 17:54 GMT+01:00 Obenchain, Valerie
>  >:
>
> Hi,
>
> I downloaded your package from github, removed the dependencies on
> AnnotationHub and utils and was able to reproduce the problem for
> read.csv() but not query().
>
> I've reworked the suggested .onLoad() file in the ExperimentHubData
> vignette. Hopefully this is a more straightforward implementation; the
> helpers in ExperimentHub incorporate the call to query() but not
> read.csv(). If you use the suggested .onLoad() then yes, you will need
> to import utils and importFrom(utils, read.csv) in the NAMESPACE.
> Changes are in ExperimentHub 1.1.2 and ExperimentHubData 1.1.4.
>
> Let me know if you run into problems.
>
> Valerie
>
> On 12/01/2016 07:13 AM, Marcin Kosiński wrote:
> > Hi Valerie,
> >
> > Thanks for the responce. Yes I have ExperimentHub in Depends.
> >
> > In the following code results I present the `query` NOTE that comes
> > out after devtools::check().
> > Then I present the content of my DESCRIPTION file and NAMESPACE.
> > After I added AnnotationHub to Imports and importFrom(AnnotationHub,
> > query) to NAMESPACE, the NOTE disappeared
> >
> >
> >
> > > devtools::check()
> > Updating RTCGA.clinical.20160128 documentation
> > Loading RTCGA.clinical.20160128
> > Setting env vars
> >
> --
> > CFLAGS  : -Wall -pedantic
> > CXXFLAGS: -Wall -pedantic
> > Building RTCGA.clinical.20160128
> > --
> > '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save
> --no-restore
> > --quiet CMD build  \
> >   '/home/mkosinski/RTCGA.clinical.20160128' --no-resave-data
> --no-manual
> >
> > * checking for file
> > ‘/home/mkosinski/RTCGA.clinical.20160128/DESCRIPTION’ ... OK
> > * preparing ‘RTCGA.clinical.20160128’:
> > * checking DESCRIPTION meta-information ... OK
> > * installing the package to build vignettes
> > * creating vignettes ... OK
> > * checking for LF line-endings in source and make files
> > * checking for empty or unneeded directories
> > * looking to see if a ‘data/datalist’ file should be added
> > * building ‘RTCGA.clinical.20160128_0.99.0.tar.gz’
> >
> > Setting env vars
> >
> --
> > _R_CHECK_CRAN_INCOMING_USE_ASPELL_: TRUE
> > _R_CHECK_CRAN_INCOMING_   : FALSE
> > _R_CHECK_FORCE_SUGGESTS_  : FALSE
> > Checking RTCGA.clinical.20160128
> > --
> > '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save
> --no-restore
> > --quiet CMD check  \
> >   '/tmp/RtmpWLIOjs/RTCGA.clinical.20160128_0.99.0.tar.gz' --as-cran
> > --timings  \
> >   --no-manual
> >
> > * using log directory
> ‘/tmp/RtmpWLIOjs/RTCGA.clinical.20160128.Rcheck’
> > * using R version 3.3.1 (2016-06-21)
> > * using platform: x86_64-pc-linux-gnu (64-bit)
> > * using session charset: UTF-8
> > * using options ‘--no-manual --as-cran’
> > * checking for file ‘RTCGA.clinical.20160128/DESCRIPTION’ ... OK
> > * checking extension type ... Package
> > * this is package ‘RTCGA.clinical.20160128’ version ‘0.99.0’
> > * checking package namespace information ... OK
> > * checking package dependencies ... OK
> > * checking if this is a source package ... OK
> > * checking if there is a namespace ... OK
> > * checking for executable files ... OK
> > * checking for hidden files and directories ... OK
> > * checking for portable file names ... OK
> > * checking for sufficient/correct file permissions ... OK
> > * checking whether 

Re: [Bioc-devel] download stats

[Hervé Pagès]

Hi Antonio,

Because of some ssh key issues the script that generates the stats was
not able to retrieve the HTTP log files for the last 2-3 weeks. The
problem is fixed now and the stats for November look really good :-)

  https://bioconductor.org/packages/stats/bioc/

Cheers,
H.


On 11/29/2016 02:21 PM, Hervé Pagès wrote:

Hi Antonio,

Yes the stats for November look low compared to the previous months.
Looks like we'll hardly hit the 3 distinct IPs for the whole
Bioconductor software repository. Could be genuine though. I'll check
what's going on.

Thanks for bringing this to our attention,
H.

On 11/29/2016 01:51 PM, Antonio Colaprico wrote:

Dear all,
Dear Hervè,

I noted something strange with the download stats in November if you
consider even default Bioconductor packages (*BiocInstaller* (26209)
,
*BiocGenerics* (18864)
, *IRanges*
(18129)
 etc

they are showing about 50% of the download stats compared to other
months of the year.

I know my post is similar to one posted by Kasper indeed I had the same
sensation maybe because there is Christmas atmosphere around.
Therefore if I'm not mistaken or I lost some news about the stats how
Kasper did know already about this issue 3 weeks ago? ;-)

@Hervè please when you have time can you check them?

Thank you in advance.
Best,
Antonio



2016-11-08 19:04 GMT+01:00 Kasper Daniel Hansen
>:

This is a bit embarrassing.  Somehow I was convinced it was
December.  All
looks fine.("... you have gained a level in Distracted
Professorship").

Kasper

On Tue, Nov 8, 2016 at 11:50 AM, Hervé Pagès > wrote:

> Hi Kasper,
>
> The download stats just got updated:
>
>   http://bioconductor.org/packages/stats/

>
> They are updated twice a week, on Tuesday and Friday between 8
> and 9 AM PST. Note that because of how the download log files are
> generated and propagated to the machine where the stats are
computed,
> and because of the time it takes to generate the stats reports for
> all the packages, the current stats don't take into account the
> downloads that happened during the last 24 hours (more or less).
>
> Cheers,
> H.
>
>
> On 11/08/2016 07:50 AM, Kasper Daniel Hansen wrote:
>
>> It was pointed out to me that the (sub) heading on the page tells
me that
>> the script for counting downloads was last run Nov 4th,
explaining the
>> discrepancy.
>>
>> On Tue, Nov 8, 2016 at 9:24 AM, Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com
> wrote:
>>
>> Is there something wrong with the download stats in November.
All the
>>> packages I look at have lost about 85-90% compared to other
months of the
>>> year:
>>>   http://bioconductor.org/packages/stats/bioc/GenomicRanges/

>>>
>>> Best,
>>> Kasper
>>>
>>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org 
mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

[[alternative HTML version deleted]]

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







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

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

Re: [Bioc-devel] [Bioc-degel] AnnotationHub needed in the description of the ExperimentHubData

[Marcin Kosiński]

Hi Valerie,

Thanks for looking around.
Have you provided this changes to the vignette?
In
https://bioconductor.org/packages/devel/bioc/vignettes/ExperimentHubData/inst/doc/ExperimentHubData.html#bug-fixes
devel there looks to be a code appearance issue in chapter
2.2 Building the software package -> documentation data loading

check release vignette
https://bioconductor.org/packages/release/bioc/vignettes/ExperimentHubData/inst/doc/ExperimentHubData.html

2016-12-05 17:54 GMT+01:00 Obenchain, Valerie <
valerie.obench...@roswellpark.org>:

> Hi,
>
> I downloaded your package from github, removed the dependencies on
> AnnotationHub and utils and was able to reproduce the problem for
> read.csv() but not query().
>
> I've reworked the suggested .onLoad() file in the ExperimentHubData
> vignette. Hopefully this is a more straightforward implementation; the
> helpers in ExperimentHub incorporate the call to query() but not
> read.csv(). If you use the suggested .onLoad() then yes, you will need
> to import utils and importFrom(utils, read.csv) in the NAMESPACE.
> Changes are in ExperimentHub 1.1.2 and ExperimentHubData 1.1.4.
>
> Let me know if you run into problems.
>
> Valerie
>
> On 12/01/2016 07:13 AM, Marcin Kosiński wrote:
> > Hi Valerie,
> >
> > Thanks for the responce. Yes I have ExperimentHub in Depends.
> >
> > In the following code results I present the `query` NOTE that comes
> > out after devtools::check().
> > Then I present the content of my DESCRIPTION file and NAMESPACE.
> > After I added AnnotationHub to Imports and importFrom(AnnotationHub,
> > query) to NAMESPACE, the NOTE disappeared
> >
> >
> >
> > > devtools::check()
> > Updating RTCGA.clinical.20160128 documentation
> > Loading RTCGA.clinical.20160128
> > Setting env vars
> > 
> --
> > CFLAGS  : -Wall -pedantic
> > CXXFLAGS: -Wall -pedantic
> > Building RTCGA.clinical.20160128
> > --
> > '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save --no-restore
> > --quiet CMD build  \
> >   '/home/mkosinski/RTCGA.clinical.20160128' --no-resave-data --no-manual
> >
> > * checking for file
> > ‘/home/mkosinski/RTCGA.clinical.20160128/DESCRIPTION’ ... OK
> > * preparing ‘RTCGA.clinical.20160128’:
> > * checking DESCRIPTION meta-information ... OK
> > * installing the package to build vignettes
> > * creating vignettes ... OK
> > * checking for LF line-endings in source and make files
> > * checking for empty or unneeded directories
> > * looking to see if a ‘data/datalist’ file should be added
> > * building ‘RTCGA.clinical.20160128_0.99.0.tar.gz’
> >
> > Setting env vars
> > 
> --
> > _R_CHECK_CRAN_INCOMING_USE_ASPELL_: TRUE
> > _R_CHECK_CRAN_INCOMING_   : FALSE
> > _R_CHECK_FORCE_SUGGESTS_  : FALSE
> > Checking RTCGA.clinical.20160128
> > --
> > '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save --no-restore
> > --quiet CMD check  \
> >   '/tmp/RtmpWLIOjs/RTCGA.clinical.20160128_0.99.0.tar.gz' --as-cran
> > --timings  \
> >   --no-manual
> >
> > * using log directory ‘/tmp/RtmpWLIOjs/RTCGA.clinical.20160128.Rcheck’
> > * using R version 3.3.1 (2016-06-21)
> > * using platform: x86_64-pc-linux-gnu (64-bit)
> > * using session charset: UTF-8
> > * using options ‘--no-manual --as-cran’
> > * checking for file ‘RTCGA.clinical.20160128/DESCRIPTION’ ... OK
> > * checking extension type ... Package
> > * this is package ‘RTCGA.clinical.20160128’ version ‘0.99.0’
> > * checking package namespace information ... OK
> > * checking package dependencies ... OK
> > * checking if this is a source package ... OK
> > * checking if there is a namespace ... OK
> > * checking for executable files ... OK
> > * checking for hidden files and directories ... OK
> > * checking for portable file names ... OK
> > * checking for sufficient/correct file permissions ... OK
> > * checking whether package ‘RTCGA.clinical.20160128’ can be installed
> > ... OK
> > * checking installed package size ... NOTE
> >   installed size is 18.2Mb
> >   sub-directories of 1Mb or more:
> > data  18.0Mb
> > * checking package directory ... OK
> > * checking ‘build’ directory ... OK
> > * checking DESCRIPTION meta-information ... OK
> > * checking top-level files ... NOTE
> > Non-standard file/directory found at top level:
> >   ‘createTCGA.R’
> > * checking for left-over files ... OK
> > * checking index information ... OK
> > * checking package subdirectories ... OK
> > * checking R files for non-ASCII characters ... OK
> > * checking R files for syntax errors ... OK
> > * checking whether the package can be loaded ... OK
> > * checking whether the package can be loaded with stated dependencies
> > ... OK
> > * checking whether the package can be unloaded cleanly ... OK
> > * checking whether the namespace 

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

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