[Rd] strptime problem for 2004-10-03 02:00:00
Hello, I at first thought this was a system or locale issue, but since it occurs on both Windows and Linux and only for 2004 (AFAIK) I report it. I have a problem with as.POSIXct for the hour between "2004-10-03 02:00:00 GMT" and "2004-10-03 02:59:59 GMT". In short, the 2 AM (GMT) hour in 2004 (but not in other years) is interpreted as 1 AM by strptime: (I use ISOdatetime as a convenience). ## Windows XP ISOdatetime(2004, 10, 3, 2, 0, 0, tz = "GMT") ##[1] "2004-10-03 01:00:00 GMT" ISOdatetime(2004, 10, 3, 1, 0, 0, tz = "GMT") ##[1] "2004-10-03 01:00:00 GMT" ISOdatetime(2005, 10, 3, 2, 0, 0, tz = "GMT") ##[1] "2005-10-03 02:00:00 GMT" ISOdatetime(2005, 10, 3, 1, 0, 0, tz = "GMT") ## [1] "2005-10-03 01:00:00 GMT" I've not explored it for other years, but it is not a problem for the same time in previous and next years. I only found it as I have a continuous sequence of date-times that cover that time period, the problem is not created by traversing that time with seq.POSIXt. I usually use Windows XP, below I also give results on Linux (release "2.4.21-37.ELsmp"). On that machine the times are incorrect in the other direction (in 2004, 2 AM is interpreted as 3 AM). My (Windows) system is set to automatically adjust for daylight summer time, and if I uncheck this and restart R the problem is "fixed". I don't know how I would do that on Linux, but it's a server anyway so I couldn't. ## R 2.2.0 ## Windows XP, SP2 ## System time is set to (GMT+10:00) Hobart - Tasmanian Summer Time (1 hour forward of GMT+10) Sys.getlocale() ## [1] "LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252" Try for 2004 (t1 <- ISOdatetime(2004, 10, 3, 1, 0, 0, tz = "GMT")) ##[1] "2004-10-03 01:00:00 GMT" (t2 <- ISOdatetime(2004, 10, 3, 2, 0, 0, tz = "GMT")) ##[1] "2004-10-03 01:00:00 GMT" ## no difference - why? t2 - t1 ## Time difference of 0 secs ## Try for 2005 (t1 <- ISOdatetime(2005, 10, 3, 1, 0, 0, tz = "GMT")) ##[1] "2005-10-03 01:00:00 GMT" (t2 <- ISOdatetime(2005, 10, 3, 2, 0, 0, tz = "GMT") ) ##[1] "2005-10-03 02:00:00 GMT" ## 1 hour difference - as expected t2 - t1 ## Time difference of 1 hours LINUX ## R 2.2.0 ## Linux (release "2.4.21-37.ELsmp" ## System time is set to (EST) - summer time (I don't know how to find more about this) Sys.getlocale() ## [1] "LC_CTYPE=en_AU.UTF-8;LC_NUMERIC=C;LC_TIME=en_AU.UTF-8;LC_COLLATE=en_AU.UTF-8;LC_MONETARY=en_AU.UTF-8;LC_MESSAGES=en_AU.UTF-8;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C" Try for 2004 (t1 <- ISOdatetime(2004, 10, 3, 1, 0, 0, tz = "GMT")) ## [1] "2004-10-03 01:00:00 GMT" (t2 <- ISOdatetime(2004, 10, 3, 2, 0, 0, tz = "GMT")) ##[1] "2004-10-03 03:00:00 GMT" ## difference of 2 hours - why? t2 - t1 ## Time difference of 2 hours ## Try for 2005 (t1 <- ISOdatetime(2005, 10, 3, 1, 0, 0, tz = "GMT")) ##[1] "2005-10-03 01:00:00 GMT" (t2 <- ISOdatetime(2005, 10, 3, 2, 0, 0, tz = "GMT") ) ##[1] "2005-10-03 02:00:00 GMT" ## one hour difference as expected t2 - t1 ## Time difference of 1 hours __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strptime problem for 2004-10-03 02:00:00
Great. Thanks for confirmation. Cheers, Mike. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---- Message: 16 Date: Tue, 25 Oct 2005 21:33:54 +0100 (BST) From: Prof Brian Ripley <[EMAIL PROTECTED]> Subject: Re: [Rd] strptime problem for 2004-10-03 02:00:00 To: Michael Sumner <[EMAIL PROTECTED]> Cc: r-devel@stat.math.ethz.ch Message-ID: <[EMAIL PROTECTED]> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed It's a bug, a rather rare one. 2004-10-03 02:00:00 does not exist in your time zone, and in trying to find out if the time is on DST or not it has failed to find out. It needs to be told that GMT is never on DST so not to bother. On Linux, running R with TZ="GMT" set should fix this. Windows is harder to control since it does not distinguish the UK timezone from GMT. There is a bugfix now in R-devel. It may migrate to R-patched in due course. On Tue, 25 Oct 2005, Michael Sumner wrote: >> Hello, I at first thought this was a system or locale issue, but since >> it occurs on >> both Windows and Linux and only for 2004 (AFAIK) I report it. >> >> I have a problem with as.POSIXct for the hour between >> "2004-10-03 02:00:00 GMT" and "2004-10-03 02:59:59 GMT". >> >> In short, the 2 AM (GMT) hour in 2004 (but not in other years) is >> interpreted as 1 AM by strptime: >> (I use ISOdatetime as a convenience). >> >> ## Windows XP >> >> ISOdatetime(2004, 10, 3, 2, 0, 0, tz = "GMT") >> ##[1] "2004-10-03 01:00:00 GMT" >> ISOdatetime(2004, 10, 3, 1, 0, 0, tz = "GMT") >> ##[1] "2004-10-03 01:00:00 GMT" >> >> ISOdatetime(2005, 10, 3, 2, 0, 0, tz = "GMT") >> ##[1] "2005-10-03 02:00:00 GMT" >> ISOdatetime(2005, 10, 3, 1, 0, 0, tz = "GMT") >> ## [1] "2005-10-03 01:00:00 GMT" >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Terminology clarification (Re: GPL and R Community Policies (Rcpp)
Christ, can we remove all references from the mailing lists while we're at it? On Sat, Dec 4, 2010 at 7:49 AM, Dominick Samperi wrote: > Dirk, > > Please let me know whether or not you will comply with my request to remove > references to my name in Rcpp (except copyright notices). > > Thanks, > Dominick > > On Thu, Dec 2, 2010 at 6:28 PM, Dominick Samperi wrote: > >> >> >> On Thu, Dec 2, 2010 at 5:58 PM, Dirk Eddelbuettel wrote: >> >>> >>> On 2 December 2010 at 17:23, Dominick Samperi wrote: >>> | OK, since you are so accomodating, then please remove all reference to >>> | my name from Rcpp as I do not want to be subject to arbitrary revisions >>> of >>> | my status. I may not have the right to say how my prior work will be >>> used, >>> | but I think I have the right to ask that my name not be used in the way >>> | it is used in the recent update. >>> >>> As I pointed out, you change your mind on this every 12 months, limiting >>> my >>> patience and willingness for these dances. It has also been suggested by >>> other than attribution is clearer if you listed as the maintainer of the >>> 2005/2006 code that we started from in 2008. >>> >> >> The change that this thread is a reaction to happened a few days ago, not >> 12 months ago. If I wavered in the past it was because I was being >> forced to compete with my own work, not a pleasant place to be. >> >> Are you telling me that you refuse to stop using my name >> in Rcpp (except in copyright notices)? >> >> Are you telling me that you will continue to use my name and >> update the associated status as you see fit, whether or not I >> approve or consent to those changes? >> >> Please answer yes or no. >> >> Thanks, >> Dominick >> >> >> > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Terminology clarification (Re: GPL and R Community Policies (Rcpp)
Well, I'm very sorry for the outburst, it was completely inappropriate. I don't actually mind the inconvenience - it's rather instructive as to how badly things can go. I was lasshing out as it's really just ironic that you want to stamp out references to yourself in a package (how many on this list really knew the details before, or cared?) but have now immortalized your contribution in the loudest way here on a list where it's really not relevant. Cheers, Mike. On Sun, Dec 5, 2010 at 2:17 AM, Dominick Samperi wrote: > > > On Sat, Dec 4, 2010 at 8:11 AM, Michael Sumner wrote: >> >> Christ, can we remove all references from the mailing lists while we're at >> it? > > Look, I want to release software to CRAN, and I would like to > do it without having to explain those remarks in Rcpp. I understand > your frustration, but the authors of Rcpp have made it clear that > private emails will be ignored. I think I have the right to decline > the kind of "acknowledgement" that appears in Rcpp, and there > is no rule that says it must be retained. > > This is a very simple resolution that would end this thread (to > the delight of many readers I am sure). > > Sorry for the inconvenience, > Dominick > >> >> >> >> On Sat, Dec 4, 2010 at 7:49 AM, Dominick Samperi >> wrote: >> > Dirk, >> > >> > Please let me know whether or not you will comply with my request to >> > remove >> > references to my name in Rcpp (except copyright notices). >> >> > >> > Thanks, >> > Dominick >> > >> > On Thu, Dec 2, 2010 at 6:28 PM, Dominick Samperi >> > wrote: >> > >> >> >> >> >> >> On Thu, Dec 2, 2010 at 5:58 PM, Dirk Eddelbuettel >> >> wrote: >> >> >> >>> >> >>> On 2 December 2010 at 17:23, Dominick Samperi wrote: >> >>> | OK, since you are so accomodating, then please remove all reference >> >>> to >> >>> | my name from Rcpp as I do not want to be subject to arbitrary >> >>> revisions >> >>> of >> >>> | my status. I may not have the right to say how my prior work will be >> >>> used, >> >>> | but I think I have the right to ask that my name not be used in the >> >>> way >> >>> | it is used in the recent update. >> >>> >> >>> As I pointed out, you change your mind on this every 12 months, >> >>> limiting >> >>> my >> >>> patience and willingness for these dances. It has also been suggested >> >>> by >> >>> other than attribution is clearer if you listed as the maintainer of >> >>> the >> >>> 2005/2006 code that we started from in 2008. >> >>> >> >> >> >> The change that this thread is a reaction to happened a few days ago, >> >> not >> >> 12 months ago. If I wavered in the past it was because I was being >> >> forced to compete with my own work, not a pleasant place to be. >> >> >> >> Are you telling me that you refuse to stop using my name >> >> in Rcpp (except in copyright notices)? >> >> >> >> Are you telling me that you will continue to use my name and >> >> update the associated status as you see fit, whether or not I >> >> approve or consent to those changes? >> >> >> >> Please answer yes or no. >> >> >> >> Thanks, >> >> Dominick >> >> >> >> >> >> >> > >> > [[alternative HTML version deleted]] >> > >> > __ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> >> >> >> -- >> Michael Sumner >> Institute for Marine and Antarctic Studies, University of Tasmania >> Hobart, Australia >> e-mail: mdsum...@gmail.com > > -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] minor outdated link error in MkRules.dist
Hello, The file [R]/src/gnuwin32/MkRules.dist contains the following link: http://www.stats.ox.ac.uk/pub/Rtools/goodies/local.zip It seems this has been updated to be http://www.stats.ox.ac.uk/pub/Rtools/goodies/Win32/local.zip This in R-patched_2010-12-27_r53886. Cheers, Mike. -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem building R 2.12.1 64-bit on Windows 7
ngle continuous long stream. -u, --unbuffered load minimal amounts of data from the input files and flush the output buffers more often --help display this help and exit --version output version information and exit If no -e, --expression, -f, or --file option is given, then the first non-option argument is taken as the sed script to interpret. All remaining arguments are names of input files; if no input files are specified, then the standard input is read. GNU sed home page: <http://www.gnu.org/software/sed/>. General help using GNU software: <http://www.gnu.org/gethelp/>. make[4]: *** [Rzlib.dll] Error 4 make[3]: *** [rlibs] Error 1 make[2]: *** [../../bin/x64/R.dll] Error 2 make[1]: *** [rbuild] Error 2 make: *** [all] Error 2 -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem building R 2.12.1 64-bit on Windows 7
Hello, thank you both - in an earlier test I turned off Kaspersky completely to check that but saw no difference, but I'm only going on my memory for that. I'll check again more completely later today and also try turning on the reporting for the sed line in MkRules as Duncan suggested. I don't have an override for SYMPAT or SYMPAT64. Cheers, Mike. On Fri, Dec 31, 2010 at 10:34 AM, peter dalgaard wrote: > > On Dec 30, 2010, at 23:19 , Duncan Murdoch wrote: > >> On 10-12-30 4:13 PM, Michael Sumner wrote: >>> Hello, >>> ... >>> make[4]: *** [Rzlib.dll] Error 4 >>> make[3]: *** [rlibs] Error 1 >>> make[2]: *** [../../bin/x64/R.dll] Error 2 >>> make[1]: *** [rbuild] Error 2 >>> make: *** [all] Error 2 >> >> I don't know what's going wrong. At that point it is supposed to be making >> Rzlib.dll (as the error at the end shows it was). That is made using >> src/extra/zlib/Makefile.win. I don't see any calls to "sed" in there, but >> there's one in the implicit rule to make the .dll (in src/gnuwin32/MkRules), >> namely >> >> $(SED) -n $(SYMPAT) >> >> Do you have a definition for SYMPAT that overrides ours, or SYMPAT64 (which >> is used in ours)? >> >> If that's not it, you could remove the @ sign from the beginning of that >> line in MkRules, and see what it is trying to do just before it dies. >> >> Duncan Murdoch > > Off-the-cuff: Is there a virus scanner active on the system? We have had a > couple of reports that turned out to be antivirus software swiping files away > for checking right under the nose of their confused maker... > > -- > Peter Dalgaard > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > > -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem building R 2.12.1 64-bit on Windows 7
Hello, It seems the problem was as elementary as me mis-interpreting the instructions in 3.1.3 of the R Installation and Administration manual: "Look at ‘MkRules.dist’ and if settings need to be altered, copy it to ‘MkRules.local’ and edit the settings there." I took that to mean that you only copy the settings that need to be altered to a new local file, so the majority of required settings weren't passed to MkRules itself. "Copy it" means copy the file, not just the setting/s - a poor reading on my part, and easily checked by seeing the resulting MkRules file. make all recommended ran to completion without error, and with Kaspersky in full operation. Thanks again for the patience, I've added my updated notes below. Cheers, Mike. -- Context -- Using Rtools212.exe, with MiKTeX, no static HTML help, and no installer build. Everything installed is Run As Administrator, including the command prompt used to build R. --- Environment Variables --- These environment variables are set: PATH Rtools and MiKTeX installed, with the following at the start of PATH: c:\inst\R\Rtools\bin;c:\inst\R\Rtools\perl\bin;c:\inst\R\Rtools\MinGW\bin;c:\inst\R\Rtools\MinGW64\bin;C:\inst\MiKTeX\miktex\bin; TAR_OPTIONS Options to avoid messages when extracting sources: --no-same-owner --no-same-permissions TMPDIR I can write to this directory: G:\systemTEMP Build steps 1) Extract from the archive tar -xf R-patched_2010-12-27_r53886.tar.gz 2) Copy Rsrc "src/" and "Tcl/" into R-patched/ from the relevant 64 bit Rtools source 3) Copy [R_HOME]/src/gnuwin32/MkRules.dist as MkRules.local and make the following changes (the jpeg setting is not required I think, I just want to report exactly what I did) diff MkRules.dist MkRules.local < WIN = 32 --- > WIN = 64 64c64 < # JPEGDIR = jpeg-8a --- > JPEGDIR = jpeg-8a 4) Make cd R-patched/src/gnuwin32 make all recommended On Fri, Dec 31, 2010 at 10:53 AM, Michael Sumner wrote: > Hello, thank you both - in an earlier test I turned off Kaspersky > completely to check that but saw no difference, but I'm only going on > my memory for that. > > I'll check again more completely later today and also try turning on > the reporting for the sed line in MkRules as Duncan suggested. > > I don't have an override for SYMPAT or SYMPAT64. > > Cheers, Mike. > > > > On Fri, Dec 31, 2010 at 10:34 AM, peter dalgaard wrote: >> >> On Dec 30, 2010, at 23:19 , Duncan Murdoch wrote: >> >>> On 10-12-30 4:13 PM, Michael Sumner wrote: >>>> Hello, >>>> ... >>>> make[4]: *** [Rzlib.dll] Error 4 >>>> make[3]: *** [rlibs] Error 1 >>>> make[2]: *** [../../bin/x64/R.dll] Error 2 >>>> make[1]: *** [rbuild] Error 2 >>>> make: *** [all] Error 2 >>> >>> I don't know what's going wrong. At that point it is supposed to be making >>> Rzlib.dll (as the error at the end shows it was). That is made using >>> src/extra/zlib/Makefile.win. I don't see any calls to "sed" in there, but >>> there's one in the implicit rule to make the .dll (in >>> src/gnuwin32/MkRules), namely >>> >>> $(SED) -n $(SYMPAT) >>> >>> Do you have a definition for SYMPAT that overrides ours, or SYMPAT64 (which >>> is used in ours)? >>> >>> If that's not it, you could remove the @ sign from the beginning of that >>> line in MkRules, and see what it is trying to do just before it dies. >>> >>> Duncan Murdoch >> >> Off-the-cuff: Is there a virus scanner active on the system? We have had a >> couple of reports that turned out to be antivirus software swiping files >> away for checking right under the nose of their confused maker... >> >> -- >> Peter Dalgaard >> Center for Statistics, Copenhagen Business School >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark >> Phone: (+45)38153501 >> Email: pd@cbs.dk Priv: pda...@gmail.com >> >> > > > > -- > Michael Sumner > Institute for Marine and Antarctic Studies, University of Tasmania > Hobart, Australia > e-mail: mdsum...@gmail.com > -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Hello,
There's a problem for rasterImage when used in SDI mode in Windows,
which may be worth considering.
https://stat.ethz.ch/pipermail/r-sig-geo/2010-July/008820.html
I had off-list emails with Duncan Murdoch and Paul Murrell about this
and they determined that it was in SDI only, and there's still no
resolution for it as far as I know. I checked in the latest dev build
of 2.13.0 2011-02-04 r54221 just in case.
This has been in use in the derived function
image.SpatialGridDataFrame in the sp package since rasterImage was
released, the sp function incorporates a warning for users in SDI
mode.
Cheers, Mike.
On Wed, Feb 9, 2011 at 12:49 PM, Ben Bolker wrote:
>
> Has anyone yet tried incorporating rasterImage into the base image()
> function? It seems to make a *huge* difference, with
> a very small number of added/changed lines of code. (Of course I have
> barely tested it at all.)
> Is there any reason this *shouldn't* go into the next release?
>
>> source("image.R")
>> z <- matrix(runif(1e6),nrow=1000)
>> image(z)
>> image(z,useRaster=TRUE)
>
> (Patch against SVN 54284 attached; people can contact me if it doesn't
> go through and they want it.)
>
> Ben Bolker
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Michael Sumner
Institute for Marine and Antarctic Studies, University of Tasmania
Hobart, Australia
e-mail: mdsum...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Regarding the SDI problem, I'll check that as soon as the next
snapshot build of 2.13.0 is available from CRAN (probably a few days
from now, unless I can manage to compile it myself).
Cheers, Mike.
On Thu, Feb 10, 2011 at 9:29 AM, Ben Bolker wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
>> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
>> wrote:
>>>
>>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>>>
>>>> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
>>>> wrote:
>>>>> Ben,
>>>>>
>>>>> I have committed something analogous to R-devel (your rotation
>>>>> code was not unlike mine, I replicated the color handling from
>>>>> R internals to be consistent, I fixed the drawing limits and
>>>>> added a check for x/y conformance). Note that useRaster can
>>>>> only be used when x, y form a regular grid. Although I tried a
>>>>> lot of corner cases (requiring quite a few fixes), I'm sure I
>>>>> did not test all of them, so volunteers please give it a go and
>>>>> compare it with non-raster output.
>>>>>
>>>>> The only thing I'm not quite happy about is the argument name:
>>>>> useRaster. Personally, I hate camel case in R (it has crept in
>>>>> more recently making it horribly inconsistent) so please feel
>>>>> free to suggest a better name ;).
>>>>
>>>> It.is.spelled.camelCase.
>>>>
>>>
>>> Fortunately not in English ;)
>>>
>>>
>>>> What about style=c("image", "raster")? This allows for future
>>>> extensions too.
>>>>
>>>
>>> Hmm.. it's not really a "style" - the output doesn't change
>>> (ideally) - it's more of a back-end specification .. also we
>>> already have oldstyle argument in image() adding to the confusion
>>> ...
>>
>> flavor=c("image", "raster") renderer=c("image", "raster")
>> backend=c("image", "raster") ...
>
> Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
> or do we need a warning/workaround there?)
>
> I like "backend", or possibly "method"
>
> One minor consideration: if "raster" eventually becomes the default
> (as I hope it will), there would need to be some internal logic that
> drops back to "image" if the user specifies uneven spacing and doesn't
> explicitly specify the 'backend/method' parameter ...
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
> ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
> =/da6
> -END PGP SIGNATURE-
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Michael Sumner
Institute for Marine and Antarctic Studies, University of Tasmania
Hobart, Australia
e-mail: mdsum...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Hello, I'm afraid the SDI graphics issue is still a problem in 2.13.0
2011-02-09 r54308.
To reproduce, in a fresh R session (Windows in SDI mode):
## create a dummy dataset
m<- matrix(c(0.2, 0.4, 0.6, 0.8), 2, 2)
## simple helper function to open the windows() device and plot the matrix
draw.f<- function(x) {
plot(0, xlim = c(0, 1), ylim = c(0, 1))
rasterImage(x, 0, 0, 1, 1, interpolate = FALSE)
}
draw.f(m)
## repeat the following 2 lines five times:
dev.off()
draw.f(m)
On the fifth attempt, only the background plot appears - but the
raster is visible on resize of the windows() device.
Cheers, Mike.
sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-09 r54308)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On Thu, Feb 10, 2011 at 5:31 PM, baptiste auguie
wrote:
> Dear all,
>
> Back when grid.raster() was introduced, it was suggested that perhaps
> grid.rect() could use grid.raster() in case of even spacing. The
> response at the time was that it would be best to keep the two
> functions separate at a lower level, that is grid.rect() and
> grid.raster(), but perhaps a new function grid.image() could be
> proposed at a higher level with the two possible backends. If this is
> done in grid graphics, perhaps the same convention could be used for
> base graphics: image() would be high level with the backend option,
> and a new function ("tiles()", perhaps?) would implement the current
> behavior of image().
>
> In any case, it would be nice to have a unified scheme to switch
> between "tiles" and raster; currently lattice (panl.levelplot.raster)
> and a few other packages all do it separately.
>
> Best wishes,
>
> baptiste
>
>
>
> On 9 February 2011 23:29, Ben Bolker wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
>>> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
>>> wrote:
>>>>
>>>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>>>>
>>>>> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
>>>>> wrote:
>>>>>> Ben,
>>>>>>
>>>>>> I have committed something analogous to R-devel (your rotation
>>>>>> code was not unlike mine, I replicated the color handling from
>>>>>> R internals to be consistent, I fixed the drawing limits and
>>>>>> added a check for x/y conformance). Note that useRaster can
>>>>>> only be used when x, y form a regular grid. Although I tried a
>>>>>> lot of corner cases (requiring quite a few fixes), I'm sure I
>>>>>> did not test all of them, so volunteers please give it a go and
>>>>>> compare it with non-raster output.
>>>>>>
>>>>>> The only thing I'm not quite happy about is the argument name:
>>>>>> useRaster. Personally, I hate camel case in R (it has crept in
>>>>>> more recently making it horribly inconsistent) so please feel
>>>>>> free to suggest a better name ;).
>>>>>
>>>>> It.is.spelled.camelCase.
>>>>>
>>>>
>>>> Fortunately not in English ;)
>>>>
>>>>
>>>>> What about style=c("image", "raster")? This allows for future
>>>>> extensions too.
>>>>>
>>>>
>>>> Hmm.. it's not really a "style" - the output doesn't change
>>>> (ideally) - it's more of a back-end specification .. also we
>>>> already have oldstyle argument in image() adding to the confusion
>>>> ...
>>>
>>> flavor=c("image", "raster") renderer=c("image", "raster")
>>> backend=c("image", "raster") ...
>>
>> Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
>> or do we need a warning/workaround there?)
>>
>> I like "backend", or possibly "method"
>>
>> One minor consideration: if "raster" eventually becomes the default
>> (as I hope it will), there would need to be some internal logic that
>> drops back to "image" if the user specifies uneven spacing and doesn't
>> explicitly specify the 'backend/method' parameter ...
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
>> ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
>> =/da6
>> -END PGP SIGNATURE-
>>
>> __
>> 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
>
--
Michael Sumner
Institute for Marine and Antarctic Studies, University of Tasmania
Hobart, Australia
e-mail: mdsum...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Hello, that appears to have fixed it. Thank you very much.
I can now repeat the reported workflow and the image appears on the
fifth (and subsequent) calls.
Cheers, Mike.
sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-11 r54330)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On Fri, Feb 11, 2011 at 12:41 PM, Paul Murrell wrote:
> Hi
>
> Just committed another fix that solves this problem for me at least. If you
> want to test for yourself, the magic revision number that you are looking
> for is r54330.
>
> Thanks again for your help.
>
> Paul
>
> On 10/02/2011 7:54 p.m., Michael Sumner wrote:
>>
>> Hello, I'm afraid the SDI graphics issue is still a problem in 2.13.0
>> 2011-02-09 r54308.
>>
>> To reproduce, in a fresh R session (Windows in SDI mode):
>>
>> ## create a dummy dataset
>> m<- matrix(c(0.2, 0.4, 0.6, 0.8), 2, 2)
>>
>> ## simple helper function to open the windows() device and plot the matrix
>> draw.f<- function(x) {
>> plot(0, xlim = c(0, 1), ylim = c(0, 1))
>> rasterImage(x, 0, 0, 1, 1, interpolate = FALSE)
>> }
>>
>> draw.f(m)
>>
>> ## repeat the following 2 lines five times:
>>
>> dev.off()
>> draw.f(m)
>>
>> On the fifth attempt, only the background plot appears - but the
>> raster is visible on resize of the windows() device.
>>
>> Cheers, Mike.
>>
>> sessionInfo()
>> R version 2.13.0 Under development (unstable) (2011-02-09 r54308)
>> Platform: x86_64-pc-mingw32/x64 (64-bit)
>>
>> locale:
>> [1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
>> [3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
>> [5] LC_TIME=English_Australia.1252
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>>
>>
>> On Thu, Feb 10, 2011 at 5:31 PM, baptiste auguie
>> wrote:
>>>
>>> Dear all,
>>>
>>> Back when grid.raster() was introduced, it was suggested that perhaps
>>> grid.rect() could use grid.raster() in case of even spacing. The
>>> response at the time was that it would be best to keep the two
>>> functions separate at a lower level, that is grid.rect() and
>>> grid.raster(), but perhaps a new function grid.image() could be
>>> proposed at a higher level with the two possible backends. If this is
>>> done in grid graphics, perhaps the same convention could be used for
>>> base graphics: image() would be high level with the backend option,
>>> and a new function ("tiles()", perhaps?) would implement the current
>>> behavior of image().
>>>
>>> In any case, it would be nice to have a unified scheme to switch
>>> between "tiles" and raster; currently lattice (panl.levelplot.raster)
>>> and a few other packages all do it separately.
>>>
>>> Best wishes,
>>>
>>> baptiste
>>>
>>>
>>>
>>> On 9 February 2011 23:29, Ben Bolker wrote:
>>>>
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA1
>>>>
>>>> On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
>>>>>
>>>>> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
>>>>> wrote:
>>>>>>
>>>>>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>>>>>>
>>>>>>> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Ben,
>>>>>>>>
>>>>>>>> I have committed something analogous to R-devel (your rotation
>>>>>>>> code was not unlike mine, I replicated the color handling from
>>>>>>>> R internals to be consistent, I fixed the drawing limits and
>>>>>>>> added a check for x/y conformance). Note that useRaster can
>>>>>>>> only be used when x, y form a regular grid. Although I tried a
>>>>>>>> lot of corner cases (requiring quite a few fixes), I'm sure I
>>>>>>>> did not test all of them, so volunteers please give it a go and
>>>>>>>> compare it with non-raster output.
>>>>>
Re: [Rd] Recursive objects
Fortune! On Wed, May 4, 2011 at 11:24 PM, Barry Rowlingson < b.rowling...@lancaster.ac.uk> wrote: > On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham wrote: > > > Any hints as to what to search for? > > For recursive objects, search for recursive objects. > > Barry > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] navigation mode(s) in rgl
Hello, I've CCd' Duncan Murdoch as the rgl maintainer, but I'm also keen to hear from the broader community of any insights. In rgl my understanding is that there's only one rotation-navigation mode, where you left-click hold and the view pivots abound the centre of the scene. In other tools, including Google Earth, that is the default behaviour but there's also a click-centric mode where the view pivots about the point clicked on. I haven't found the right terminology for this, but I call it 1) Data-centric navigation, rotating about the centre of the data in the scene (invoked by left-click-drag in rgl and GE and others) 2) Click-centric navigation, rotating about the point clicked on (invoked by centre-click-drag in GE and others, but not rgl) My questions: 1) I'd appreciate any guidance on my terminology here, whether I'm making sense and ask for pointers to resources that explore this properly 2) Is there scope to add this "click-centric" navigation to rgl? I'd appreciate any pointers to how it could be done - is it an rgl-level feature, or deeper down? I know that "click-centric" clicked-on point has a different meaning in different contexts, in GE clearly it finds the nearest point intersecting the globe surface since that is a always-present structure, but other tools must have rules to specify where the pivot point is - either intersecting a data element or somewhere in the scene. The data-centric mode is fine for small scenes with a limited scope, but when the extent covered by data is large it's quite unwieldy to focus in on specific parts of the scene. I know this could be controlled by pushing/popping elements in the scene but the navigation mode obviously offers more flexibility. Thank you. Cheers, Mike. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] navigation mode(s) in rgl
On Thu, 5 Nov 2015 at 14:01 Duncan Murdoch wrote: > On 04/11/2015 6:56 PM, Michael Sumner wrote: > > Hello, I've CCd' Duncan Murdoch as the rgl maintainer, but I'm also keen > to > > hear from the broader community of any insights. > > > > In rgl my understanding is that there's only one rotation-navigation > mode, > > where you left-click hold and the view pivots abound the centre of the > > scene. > > That's not quite true: there are several modes built in, and the > possibility of adding your own. > > > In other tools, including Google Earth, that is the default behaviour but > > there's also a click-centric mode where the view pivots about the point > > clicked on. > > > > I haven't found the right terminology for this, but I call it > > > > 1) Data-centric navigation, rotating about the centre of the data in the > > scene (invoked by left-click-drag in rgl and GE and others) > > 2) Click-centric navigation, rotating about the point clicked on (invoked > > by centre-click-drag in GE and others, but not rgl) > > > > My questions: > > > > 1) I'd appreciate any guidance on my terminology here, whether I'm making > > sense and ask for pointers to resources that explore this properly > > 2) Is there scope to add this "click-centric" navigation to rgl? I'd > > appreciate any pointers to how it could be done - is it an rgl-level > > feature, or deeper down? > > If I understand your description properly, you can add it using the > "user" mouse mode (see ?par3d). You should also see that help topic for > a description of how rendering is done, and ?rgl.setMouseCallbacks > for an example of doing it. > > The hard part in doing this is in working out *exactly* what you want > the mouse to do. If you work that out for the mode you want but find > the "user" mode is unsatisfactory for some reason, I'd be willing to add > it as another built in mode. > > Duncan Murdoch > > Thank you, I can see the way forward now. Cheers, Mike. > > > > I know that "click-centric" clicked-on point has a different meaning in > > different contexts, in GE clearly it finds the nearest point intersecting > > the globe surface since that is a always-present structure, but other > tools > > must have rules to specify where the pivot point is - either > intersecting a > > data element or somewhere in the scene. > > > > The data-centric mode is fine for small scenes with a limited scope, but > > when the extent covered by data is large it's quite unwieldy to focus in > on > > specific parts of the scene. I know this could be controlled by > > pushing/popping elements in the scene but the navigation mode obviously > > offers more flexibility. > > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Update CRAN submission process
On Sat, 28 May 2016 at 05:59 Patrick Perry wrote: > > The CRAN submission process seems in need of a massive overhaul. Why has > this process not been automated yet? > > Many improvements to R come via extensions to R. See Hadley Wickham's R Packages book for ways to improve the process with devtools. Cheers, Mike. — > Patrick Perry > Assistant Professor > NYU Stern School of Business > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] polypath winding rule with transparency
Hi, I see different results in png() and pdf() for polypath() on Windows
when using the "winding" rule
## overlapping, both clock-wise
x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
pfun <- function() {
plot(x)
polypath(x * 0.8 + 0.2, rule = "winding", col = "#BEBEBE80")
polypath(x, rule = "winding", col = "#BEBEBE80")
}
## output "windows.png/pdf" or "unix.png/pdf"
label <- .Platform$OS.type
png(sprintf("%s.png", label))
pfun()
dev.off()
pdf(sprintf("%s.pdf", label))
pfun()
dev.off()
Visually, the result in the "windows.png" file is as if the "evenodd" rule
was specified. All other examples unix.pdf, unix.png, windows.pdf give me
the expected result - which is "all bounded regions shaded grey, with two
tones for the different regions of overlap". The unexpected result is the
completely transparent region.
Is this a known/expected difference on Windows? I see the unexpected
result in 3.3.1 and in R version 3.3.1 Patched (2016-07-27 r70991) on
Windows.
Cheers, Mike.
--
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] polypath winding rule with transparency
Hello,
it's probably worth adding that this is not a problem with pathGrob, only
polypath.
This code is sufficient to demonstrate the problem in Windows.
## overlapping, both clock-wise
x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
## only a problem on Windows windows() and png()
plot(x);polypath(x, rule = "winding", col = "#BEBEBE80")
This code shows the same behaviour on different systems/devices.
## no problem on Windows/Linux/PNG/PDF ...
library(grid)
grid.newpage()
pushViewport(viewport(0.5, 0.5, width = 1, height = 1))
grid.draw(pathGrob(x[,1], x[,2], rule = "winding", gp = gpar(fill =
"#BEBEBE80")))
Cheers, Mike.
On Wed, 3 Aug 2016 at 16:24 Michael Sumner wrote:
> Hi, I see different results in png() and pdf() for polypath() on Windows
> when using the "winding" rule
>
> ## overlapping, both clock-wise
> x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
> c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
>
> pfun <- function() {
> plot(x)
> polypath(x * 0.8 + 0.2, rule = "winding", col = "#BEBEBE80")
> polypath(x, rule = "winding", col = "#BEBEBE80")
> }
>
> ## output "windows.png/pdf" or "unix.png/pdf"
> label <- .Platform$OS.type
> png(sprintf("%s.png", label))
> pfun()
> dev.off()
> pdf(sprintf("%s.pdf", label))
> pfun()
> dev.off()
>
>
> Visually, the result in the "windows.png" file is as if the "evenodd" rule
> was specified. All other examples unix.pdf, unix.png, windows.pdf give me
> the expected result - which is "all bounded regions shaded grey, with two
> tones for the different regions of overlap". The unexpected result is the
> completely transparent region.
>
> Is this a known/expected difference on Windows? I see the unexpected
> result in 3.3.1 and in R version 3.3.1 Patched (2016-07-27 r70991) on
> Windows.
>
> Cheers, Mike.
> --
> Dr. Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> 203 Channel Highway
> Kingston Tasmania 7050 Australia
>
> --
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Re: polypath winding rule with transparency
On Thu, 4 Aug 2016 at 11:17 Paul Murrell wrote:
> Hi
>
> Just to clarify, I think this IS a problem with grid.path() as well as
> polypath().
>
>
Hi, oh dear - sorry about that
I appreciate the deeper explanation, I knew about the id aspect in grid,
but just forgot in my haste.
I'll be more careful with examples if I find any more clues.
Cheers, Mike.
> For the example you give, grid.path() diverts to drawing a polygon
> (because there is no 'id' specified), and the NAs in 'x' generate two
> separate polygons, which get drawn one on top of the other.
>
> The correct analogy to the polypath() example is ...
>
> x2 <- matrix(x[!is.na(x)], ncol=2)
> grid.path(x2[,1], x2[,2], id=rep(1:2, each=4),
>rule="winding", gp=gpar(="#BEBEBE80"))
>
> ... which produces the same (wrong) result as polypath() on Windows.
>
> Also, the grid.path() result for your example is NOT the same as the
> correct result; we do NOT want a separate shade for the intersecting
> region when the "winding" fill rule is working correctly. The fill
> should be the same across the union of the square regions (this is what
> Cairo and PDF on Linux produce).
>
> Another data point: the problem is NOT just a matter of getting the
> rules round the wrong way in the devWindows.c; using rule="evenodd"
> produces the SAME result as using rule="winding".
>
> One more data point: this is not JUST a problem with polypath().
> Creating a self-intersecting polygon and then drawing it, using
> polygon(), in windows(fillEvenOdd=FALSE) and windows(filleEvenOdd=TRUE)
> produces exactly the same result.
>
> Sadly, none of that helps to explain why the "winding" rule is not
> working on Windows :(
>
> Thanks for reporting the problem - needs more study to find out what is
> going wrong.
>
> Paul
>
> On 03/08/16 18:47, Michael Sumner wrote:
> > Hello,
> >
> > it's probably worth adding that this is not a problem with pathGrob, only
> > polypath.
> >
> > This code is sufficient to demonstrate the problem in Windows.
> >
> > ## overlapping, both clock-wise
> > x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
> > c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
> > ## only a problem on Windows windows() and png()
> > plot(x);polypath(x, rule = "winding", col = "#BEBEBE80")
> >
> > This code shows the same behaviour on different systems/devices.
> >
> > ## no problem on Windows/Linux/PNG/PDF ...
> > library(grid)
> > grid.newpage()
> > pushViewport(viewport(0.5, 0.5, width = 1, height = 1))
> > grid.draw(pathGrob(x[,1], x[,2], rule = "winding", gp = gpar(fill =
> > "#BEBEBE80")))
> >
> > Cheers, Mike.
> >
> > On Wed, 3 Aug 2016 at 16:24 Michael Sumner wrote:
> >
> >> Hi, I see different results in png() and pdf() for polypath() on Windows
> >> when using the "winding" rule
> >>
> >> ## overlapping, both clock-wise
> >> x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
> >> c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
> >>
> >> pfun <- function() {
> >> plot(x)
> >> polypath(x * 0.8 + 0.2, rule = "winding", col = "#BEBEBE80")
> >> polypath(x, rule = "winding", col = "#BEBEBE80")
> >> }
> >>
> >> ## output "windows.png/pdf" or "unix.png/pdf"
> >> label <- .Platform$OS.type
> >> png(sprintf("%s.png", label))
> >> pfun()
> >> dev.off()
> >> pdf(sprintf("%s.pdf", label))
> >> pfun()
> >> dev.off()
> >>
> >>
> >> Visually, the result in the "windows.png" file is as if the "evenodd"
> rule
> >> was specified. All other examples unix.pdf, unix.png, windows.pdf give
> me
> >> the expected result - which is "all bounded regions shaded grey, with
> two
> >> tones for the different regions of overlap". The unexpected result is
> the
> >> completely transparent region.
> >>
> >> Is this a known/expected difference on Windows? I see the unexpected
> >> result in 3.3.1 and in R version 3.3.1 Patched (2016-07-27 r70991) on
> >> Windows.
> >>
> >> Cheers, Mike.
> >> --
> >> Dr. Michael Sumner
> >> Software and Database Engineer
> >> Australian Antarctic Division
> >> 203 Channel Highway
> >> Kingston Tasmania 7050 Australia
> >>
> >> --
> > Dr. Michael Sumner
> > Software and Database Engineer
> > Australian Antarctic Division
> > 203 Channel Highway
> > Kingston Tasmania 7050 Australia
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
--
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] non-infectious license for R package?
Have the lawyers look at Microsoft R, it seems the license is not very catching ultimately. Perhaps you could use a similar ruse, or even align to that project instead. Cheers, Mike On Sat, Mar 25, 2017, 00:54 Mario Emmenlauer wrote: > > Dear All, > > I've been following this mailing list for over three years now, but > its just now that I have realized that R is licensed under GPL! :-) > > I'm not a lawyer and I don't want lawyer advice, but I'd like to get > your feedback on a license question. My goal is to develop commercial > software for image analysis of biomedical samples that may be used > i.e. in academic institutions. Since I've been an academic software > developer for long, a priority for me is to make the data and tools > easily accessibly for other developers. I have toyed with the idea to > make a (free) R package that can very efficiently fetch data from the > database and push back results for visualization. To clarify: I am > not using R in my software. I'd rather like the institutions of my > customers to have open (internal) access to their data. > > Now for the question: To efficiently get the data into R, I assume a > package (possibly in C or C++) is the most reasonable way? If yes, > would such a package automatically be infected by the GPL? If the > package links to (proprietary closed source) libraries to efficiently > access the data, would the libraries in turn be infected? > > I'm asking this very naiively because I understand statement [1] in > such a way that it is generally encouraged to make data available in > R. Obviously open source is the preferred way, but my understanding > is that also closed source extensions can add value and may be > welcome. > > I was therefore hoping that somebody has prior experience in this > regard, or can shed further light on statement [1]. Is the R-C- > interface infectious per se, even when data flows only into R, not > vice versa? If its infectious, could just the very core of R be > licensed additionally under a non-infectious license? > > Furthermore, can I avoid infecting my full software stack, for example > by making only the package open source under a permissive license? Are > there any guidelines how to legally bridge between the proprietary and > the R-world? I guess other people have tried this before, can someone > share his/her experience? > > [1] https://stat.ethz.ch/pipermail/r-devel/2009-May/053248.html > > All the best, > > Mario Emmenlauer > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ask.yes.no() function
Perhaps worth pointing out "yesno" as a candidate: https://CRAN.R-project.org/package=yesno <https://cran.r-project.org/package=yesno> Cheers, Mike On Wed, 19 Apr 2017 at 21:55 Duncan Murdoch wrote: As described in <https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17242>, R base functions are currently inconsistent in asking interactive "yes/no" type questions. One solution to this is to have a function to do it, and to use it consistently. Rather than just writing such a function and possibly missing some desirable feature, I'd like to ask if anyone can point to an existing one that is perfect (or nearly perfect, and point out what changes would be desirable)? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] polypath winding rule with transparency
On Thu, 4 Aug 2016 at 17:53 Michael Sumner wrote: > On Thu, 4 Aug 2016 at 11:17 Paul Murrell wrote: > >> Hi >> >> Just to clarify, I think this IS a problem with grid.path() as well as >> polypath(). >> >> > Hi, oh dear - sorry about that > > I appreciate the deeper explanation, I knew about the id aspect in grid, > but just forgot in my haste. > > I'll be more careful with examples if I find any more clues. > > I've found a possibly related issue, again only on Windows as far as I can see. These two plots give different results, the second is completely transparent rather than the expected light blue region on the left. Whether it works or not seems to depend on the specific geometry of the device and *not on the specific xlim interval chosen*. I can get the problem to come and by interactively resizing the window resulting from the first plot. Somehow it's related to the intersection-detection of the filled polygon with the plot region (?). pp <- matrix(c(0, 0, 0, 1, 1, 1, 1, 0, 0, 0), ncol = 2, byrow = TRUE) xlim <- c(0.24, 1.5) ## ok at xlim[1] = 0.24 ## first plot, ok (but also try resizing the window by dragging the left side out) plot(pp, main = "winding/transparent", xlim = xlim) polypath(pp, col = "#ADD8E6E6", rule = "winding") xlim <- c(0.25, 1.5) ## second plot, not ok plot(pp, main = "winding/transparent", xlim = xlim) polypath(pp, col = "#ADD8E6E6", rule = "winding") Cheers, Mike. > Cheers, Mike. > > >> For the example you give, grid.path() diverts to drawing a polygon >> (because there is no 'id' specified), and the NAs in 'x' generate two >> separate polygons, which get drawn one on top of the other. >> >> The correct analogy to the polypath() example is ... >> >> x2 <- matrix(x[!is.na(x)], ncol=2) >> grid.path(x2[,1], x2[,2], id=rep(1:2, each=4), >>rule="winding", gp=gpar(="#BEBEBE80")) >> >> ... which produces the same (wrong) result as polypath() on Windows. >> >> Also, the grid.path() result for your example is NOT the same as the >> correct result; we do NOT want a separate shade for the intersecting >> region when the "winding" fill rule is working correctly. The fill >> should be the same across the union of the square regions (this is what >> Cairo and PDF on Linux produce). >> >> Another data point: the problem is NOT just a matter of getting the >> rules round the wrong way in the devWindows.c; using rule="evenodd" >> produces the SAME result as using rule="winding". >> >> One more data point: this is not JUST a problem with polypath(). >> Creating a self-intersecting polygon and then drawing it, using >> polygon(), in windows(fillEvenOdd=FALSE) and windows(filleEvenOdd=TRUE) >> produces exactly the same result. >> >> Sadly, none of that helps to explain why the "winding" rule is not >> working on Windows :( >> >> Thanks for reporting the problem - needs more study to find out what is >> going wrong. >> >> Paul >> >> On 03/08/16 18:47, Michael Sumner wrote: >> > Hello, >> > >> > it's probably worth adding that this is not a problem with pathGrob, >> only >> > polypath. >> > >> > This code is sufficient to demonstrate the problem in Windows. >> > >> > ## overlapping, both clock-wise >> > x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9), >> > c(.1, .6, .6, .1, NA, .4, .9, .9, .4)) >> > ## only a problem on Windows windows() and png() >> > plot(x);polypath(x, rule = "winding", col = "#BEBEBE80") >> > >> > This code shows the same behaviour on different systems/devices. >> > >> > ## no problem on Windows/Linux/PNG/PDF ... >> > library(grid) >> > grid.newpage() >> > pushViewport(viewport(0.5, 0.5, width = 1, height = 1)) >> > grid.draw(pathGrob(x[,1], x[,2], rule = "winding", gp = gpar(fill = >> > "#BEBEBE80"))) >> > >> > Cheers, Mike. >> > >> > On Wed, 3 Aug 2016 at 16:24 Michael Sumner wrote: >> > >> >> Hi, I see different results in png() and pdf() for polypath() on >> Windows >> >> when using the "winding" rule >> >> >> >> ## overlapping, both clock-wise >> >> x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9), >> >> c(.1, .6, .6, .1, NA, .4, .
[Rd] interrupting Sweave leaves open sink connection
Hello, if I interrupt Sweave while it's processing a file it seemingly
leaves an open sink connection that hides printed output.
Can this be changed to reset the sink on exit? I've been baffled by
this for years.
This is seen in Windows (R Under development (unstable) (2013-10-20
r64082)) and an older Linux (R version 3.0.0 (2013-04-03)).
Run the code below in two parts with a manual interrupt to 1) to see it.
Cheers, MIke.
## 1)
## this code creates a temporary file to run Sweave
## interrupt this code before Sweave() finishes
txt <- c("\\documentclass[a4paper]{article}", "\\title{Sweave bail out}",
"\\author{M. Sumner}", "\\begin{document}", "\\maketitle", "",
"Run a loop and bail out when Sweave()ing.", "", "<<>>=",
"for (i in seq_len(1e6)) {", "if (i %% 1000 == 0)
print(sprintf(\"%i\", i))",
"Sys.sleep(0.5)", "}", "@", "", "\\end{document}")
f <- tempfile()
writeLines(txt, f)
Sweave(f)
## 2)
## now no printed output is seen
print(1)
##
sink(NULL)
## now it's back
print(1)
## [1] 1
## tidy up
## unlink(f)
--
Michael Sumner
Hobart, Australia
e-mail: mdsum...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] interrupting Sweave leaves open sink connection
Thanks very much, confirmed in Windows in R-patched (r64110) and
R-devel (r64116).
Cheers, Mike.
On Wed, Oct 23, 2013 at 10:48 PM, Duncan Murdoch
wrote:
> On 13-10-22 10:45 PM, Duncan Murdoch wrote:
>>
>> On 13-10-22 9:45 PM, Michael Sumner wrote:
>>>
>>> Hello, if I interrupt Sweave while it's processing a file it seemingly
>>> leaves an open sink connection that hides printed output.
>>>
>>> Can this be changed to reset the sink on exit? I've been baffled by
>>> this for years.
>>>
>>> This is seen in Windows (R Under development (unstable) (2013-10-20
>>> r64082)) and an older Linux (R version 3.0.0 (2013-04-03)).
>>>
>>> Run the code below in two parts with a manual interrupt to 1) to see it.
>>
>>
>> That's a bug in the Rweave driver. It runs the code in try() so that it
>> can catch errors and undo the sink, but try() doesn't catch user
>> interrupts, so it never gets undone.
>>
>> Shouldn't be too hard to fix...
>
>
> It should now be fixed in R-devel and R-patched.
>
> Likely the reason this went unfixed for so long is that the more common way
> to use Sweave is in a separate R session. If you run it in the current R
> session, the results aren't necessarily reproducible, because they may
> depend on whatever variables you have in your workspace. It's better to run
> it on its own. One way is to use the command line version
>
> R CMD Sweave ...
>
> but it can also be done by piping specific commands into an R session. I do
> it that way, because it lets me run some project management code, and lets
> me patch the Synctex information so it points to the .Rnw file.
>
> Duncan Murdoch
>
>
>>
>> Duncan Murdoch
>>
>>>
>>> Cheers, MIke.
>>>
>>> ## 1)
>>>
>>> ## this code creates a temporary file to run Sweave
>>>
>>> ## interrupt this code before Sweave() finishes
>>>
>>> txt <- c("\\documentclass[a4paper]{article}", "\\title{Sweave bail
>>> out}",
>>> "\\author{M. Sumner}", "\\begin{document}", "\\maketitle", "",
>>> "Run a loop and bail out when Sweave()ing.", "", "<<>>=",
>>> "for (i in seq_len(1e6)) {", "if (i %% 1000 == 0)
>>> print(sprintf(\"%i\", i))",
>>> "Sys.sleep(0.5)", "}", "@", "", "\\end{document}")
>>>
>>> f <- tempfile()
>>> writeLines(txt, f)
>>>
>>> Sweave(f)
>>>
>>> ## 2)
>>> ## now no printed output is seen
>>> print(1)
>>> ##
>>>
>>> sink(NULL)
>>>
>>> ## now it's back
>>> print(1)
>>> ## [1] 1
>>>
>>> ## tidy up
>>> ## unlink(f)
>>>
>>>
>>>
>>>
>>>
>>
>
--
Michael Sumner
Hobart, Australia
e-mail: mdsum...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] vignettes with similar names
In R 3.0.2 Patched (2014-01-31 r64905) and 3.0.3 beta (2014-02-25
r65077) I see a problem loading vignettes when I create a package with
two vignettes with similar names, e.g.
"vignette3"
"vignette3-install"
These seem not to be distinguished, and I get this
vignette("vignette3")
vignette ‘vignette3’ not found
vignette("vignette3-install")
Warning message:
vignette ‘vignette3-install’ found more than once,
using the one found in ‘.’
This was not an issue in 2.15.3, and it works correctly in R-dev
(2014-02-17 r65021).
Cheers, Mike.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Maintainer NOTE in R CMD Check
I believe it's just a flag to notify that the author string has changed.
You might need to send a confirmation email that yes you did mean to
change, it is just a double check for both ends. I changed my email for a
package once for some reason and made the confirmation.
Cheers, Mike
On 9 Mar 2014 12:06, "S Ellison" wrote:
> Using R 3.0.3 and Rtools 31, I now see a Note (reproduced on my R-forge
> checks) of the form
>
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: 'firstname A B lastname '
>
> where A and B are middle initials.
>
> I can change to a 'firstname lastname' form or 'INITS lastname' form and
> that removes the above Note*, but I then get a Note warning of maintainer
> change.
>
> Is either Note going to get in the way of CRAN submission? (And if one of
> them will, which one?)
>
> S Ellison
>
> *A minor aside: I couldn't find any documented reason for that, or indeed
> any restriction on the format of a maintaner's name other than 'name first
> email second in <>'; perhaps I missed something there?
>
> ***
> This email and any attachments are confidential. Any u...{{dropped:10}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] windows() device: plot does not refresh with new drawing after opening and closing a new device
Hello, I see this problem in 2.14.1, a recent dev, and 2.15.0 alpha, but not in an older build. Start the R windows console and run this code: plot(1:10);windows();dev.off();points(10:1) The second set of points does not show up until the window is minimized and restored. If the device is replaced with a file-based one (pdf, png) there's no problem. I see this behaviour on these versions: R version 2.15.0 alpha (2012-03-13 r58726) Platform: x86_64-pc-mingw32/x64 (64-bit) R Under development (unstable) (2012-02-28 r58513) Platform: x86_64-pc-mingw32/x64 (64-bit) R version 2.14.1 (2011-12-22) Platform: x86_64-pc-mingw32/x64 (64-bit) I have an old beta install of 2.13.2 where the problem does not occur: R version 2.13.2 beta (2011-09-22 r57035) Platform: x86_64-pc-mingw32/x64 (64-bit) Cheers, Mike. -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem with vignettes when S4 classes in packages overlap
Sorry about out of date trip, I appreciate the detailed discussion here and
will fix it soon once I catch up
On Wednesday, September 19, 2012, Roger Bivand wrote:
> On Tue, 18 Sep 2012, Paul Gilbert wrote:
>
>
>> ( A similar problem is also reported by Sebastian P. Luque with
>> library(maptools)
>> library(trip)
>> in the vignette as below ).
>>
>
> Thanks for bringing this up. This is caused by maptools avoiding: Depends:
> spatstat, which might create circularities. maptools and spatstat (which
> defines the classes that maptools and trip augment by adding coercion to
> and from their own or sp classes) mutually Suggest: each other. trip
> Depends: spatstat, but out of the box has no NAMESPACE - I haven't
> investigated whether adding one helps.
>
> Adding maptools to trip::Depends removes the warnings; check passes as
> before, so no side-effects I can see. The auto-generated NAMESPACE is then:
>
> # Default NAMESPACE created by R
> # Remove the previous line if you edit this file
>
> # Export all names
> exportPattern(".")
>
> # Import all packages listed as Imports or Depends
> import(
> methods,
> sp,
> spatstat,
> maptools
> )
>
> Since trip was last updated in May 2011, it is missing both a NAMESPACE
> file, and suggestion of the correct adehabitat?? package(s) - adehabitat is
> deprecated. I don't think that this is an S4 problem, I think it is about
> keeping packages in sync with the R engine, especially with regard to
> NAMESPACE, etc., and with packages named in DESCRIPTION. This may carry
> over to the main case here, but I haven't checked.
>
> Roger
>
>
>> I am writing a vignette which loads RMySQL and RPostgreSQL. This produces
>> the warning:
>>
>> Loading required package: DBI
>> Warning in .simpleDuplicateClass(def, prev) :
>> A specification for class âdbObjectIdâ in package âRPostgreSQLâ
>> seems
>> equivalent to one from package âRMySQLâ and is not turning on duplicate
>> class definitions for this class
>>
>> This can be reproduced by running
>> R CMD Sweave --pdf Atest.Stex
>>
>> where the file Atest.Stex has the lines
>>
>> \documentclass{article}
>> \usepackage{Sweave}
>> \begin{document}
>> \begin{Scode}
>> library("RMySQL")
>> library("RPostgreSQL")
>> \end{Scode}
>> \end{document}
>>
>> These warnings only happen in a vignette. They are not produced if the
>> lines are entered in an R session.
>>
>> (Using R version 2.15.1 (2012-06-22) -- "Roasted Marshmallows" on Ubuntu)
>>
>> Paul
>>
>>
> --
> Roger Bivand
> Department of Economics, NHH Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; fax +47 55 95 95 43
> e-mail: roger.biv...@nhh.no
>
--
Michael Sumner
Hobart, Australia
e-mail: mdsum...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] support for POSIXct classes in image.default axes
Hello, I would like to suggest the following change to image.default in src\library\graphics\R\image.R: 98c98 < plot(NA, NA, xlim = xlim, ylim = ylim, type = "n", xaxs = xaxs, --- > plot(x[1], y[1], xlim = xlim, ylim = ylim, type = "n", xaxs = xaxs, This provides all the support of axis.POSIXt that plot.default gives, currently the default new plot in image.default uses NAs and the axis class is ignored. This is nice for plotting time series data stored in a matrix. Here's a dummy example that shows usage with my change: data(volcano) x <- list(x = Sys.time() + seq(1, 1e6, length = nrow(volcano)), y = 1:ncol(volcano), z = volcano) ## date-time formatting on the x-axis image(x) ## date-time formatting on the y-axis image(x$y, x$x, t(x$z)) Without the change we get the very large underlying numeric values for the times on the axis. We can still override the default axis to do a workaround: : image(x, axes = FALSE) axis.POSIXct(x$x, side = 1) Cheers, Mike. -- Michael Sumner Hobart, Australia e-mail: mdsum...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] support for POSIXct classes in image.default axes
Perfect, thanks very much. I couldn't see the xlim/ylim solution which is really neat, and clearly better than my suggestion. Cheers, Mike. On Wed, Apr 17, 2013 at 6:15 PM, Prof Brian Ripley wrote: > On 12/04/2013 12:27, Michael Sumner wrote: > >> Hello, I would like to suggest the following change to image.default in >> src\library\graphics\R\image.**R: >> >> 98c98 >> < plot(NA, NA, xlim = xlim, ylim = ylim, type = "n", xaxs = xaxs, >> --- >> >>>plot(x[1], y[1], xlim = xlim, ylim = ylim, type = "n", xaxs = >>> xaxs, >>> >> >> > I think xlim, ylim is a better idea: this relies on range() preserving the > class. > > Done now (in R-devel pro tem). > > > This provides all the support of axis.POSIXt that plot.default gives, >> currently the default new plot in image.default uses NAs and the axis >> class >> is ignored. This is nice for plotting time series data stored in a matrix. >> >> Here's a dummy example that shows usage with my change: >> >> data(volcano) >> x <- list(x = Sys.time() + seq(1, 1e6, length = nrow(volcano)), y = >> 1:ncol(volcano), z = volcano) >> >> ## date-time formatting on the x-axis >> image(x) >> >> ## date-time formatting on the y-axis >> image(x$y, x$x, t(x$z)) >> >> Without the change we get the very large underlying numeric values for the >> times on the axis. >> >> We can still override the default axis to do a workaround: : >> image(x, axes = FALSE) >> axis.POSIXct(x$x, side = 1) >> >> Cheers, Mike. >> >> >> >> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Professor of Applied Statistics, > http://www.stats.ox.ac.uk/~**ripley/<http://www.stats.ox.ac.uk/~ripley/> > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > -- Michael Sumner Hobart, Australia e-mail: mdsum...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
