FWIW Microsoft provides evaluation version of Windows that can be easily installed using VirtualBox and runs for 180 days. One that I believe is the closest to the CRAN setup (Windows 2008) is: https://www.microsoft.com/en-nz/download/details.aspx?id=11093 You just tell VB to setup a Windows 2008 VM then, select the downloaded ISO as CD-ROM drive and install from it. The installation is fairly easy and then you only have to download Rtools.exe and R from CRAN. I recommend picking a custom location for R that is painless to type, e.g C:\R. To make iteration easier, I also use a shared mount from my machine (e.g. ~/packages -> E:) so I can edit and build the package on my Mac and then just run c:\R\bin\R CMD INSTALL mypackage_0.1-0.tar.gz in the Windows VM is the same directory (you need to install Guest Additions [see the VB menu] to enable shared directories - alternatively you can also just use SMB shares if you want). Cheers, Simon> On 4/03/2020, at 10:02 AM, Gabriel Becker <gabembecker at gmail.com> wrote: > > Hi Terry, > > http://win-builder.r-project.org/ and the rhub build service (which can be > invoked by the rhub package) allow on demand checks in windows > environments, though for active debugging the iteration time can be quite > painful. > > If you have access, e.g., through your employer, to a windows license you > should also be able to do use VMWare or VirtualBox (I can never remember > which one I like more) to run windows and test that way. This will have > some start up cost in effort but allows active testing and iteration. > > Hope that helps, > ~G > > On Tue, Mar 3, 2020 at 7:00 AM Therneau, Terry M., Ph.D. via R-devel < > r-devel at r-project.org> wrote: > >> My latest submission of survival3.1-10 to CRAN fails a check, but only on >> windows, which >> I don't use. >> How do I track this down? >> The test in question works fine on my Linux box. >> >> Terry >> >> >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
?I ended up finding the issue by a focused code review.
Once in the past, I had a version that would fail under one architecture but not
another,
in that case some help from Brian Ripley pointed me to the offending line of C
code.??
That line read, but did not write, at an invalid memory location.?? Starting
with the
question of "what C routines have I added or modified most recently"
along with where the
fault appeared to occur in my test suite, I started reading C code and found
one.??
Revised code passes tests on the winbuilder site.
For the curious, I had a line asking "is this patient id different than the
last patient
id" in the C routine underneath survcheck(); I'm making sure that
patients don't go
backwards in time. Essentially
?for (i=0; i< n; i) {
? ?? if (id[i] != id[i-1] )? { ...}
It is still a surprise to me that just LOOKING at this out of range element
would cause a
failure,? [i-1] never appears on the left hand side of any expressions in the
... chunk
above. Nevertheless, it was an error. ? Que sera sera
A strong thanks to those who gave solid suggestions for bringing up a local copy
of Windows.
Terry T
>>> My latest submission of survival3.1-10 to CRAN fails a check, but
only on
>>> windows, which
>>> I don't use.
>>> How do I track this down?
>>> The test in question works fine on my Linux box.
>>>
>>> Terry
>>>
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
[[alternative HTML version deleted]]
I _think_ the relevant section of the C standard is 6.5.6 Additive Operators Par 8, excerpted here:> If both the pointer operand and the result point to elements > of the same array object, or one past the last element of the > array object, the evaluation shall not produce an overflow; > otherwise, **the behavior is undefined**.This is from the [C11 draft][1], though I imagine has been part of the standard for a while.? So by doing id[-1], in this case the pointer operand is id, and the result is one element _before_ the array object, thus undefined behavior which is bad news. I'm not an expert in these matters though. [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf On Thursday, March 5, 2020, 11:39:38 AM EST, Therneau, Terry M., Ph.D. via R-devel <r-devel at r-project.org> wrote: ?I ended up finding the issue by a focused code review. Once in the past, I had a version that would fail under one architecture but not another, in that case some help from Brian Ripley pointed me to the offending line of C code.?? That line read, but did not write, at an invalid memory location.?? Starting with the question of "what C routines have I added or modified most recently" along with where the fault appeared to occur in my test suite, I started reading C code and found one.?? Revised code passes tests on the winbuilder site. For the curious, I had a line asking "is this patient id different than the last patient id" in the C routine underneath survcheck(); I'm making sure that patients don't go backwards in time. Essentially ?for (i=0; i< n; i) { ? ?? if (id[i] != id[i-1] )? { ...} It is still a surprise to me that just LOOKING at this out of range element would cause a failure,? [i-1] never appears on the left hand side of any expressions in the ... chunk above. Nevertheless, it was an error. ? Que sera sera A strong thanks to those who gave solid suggestions for bringing up a local copy of Windows. Terry T>>> My latest submission of survival3.1-10 to CRAN fails? a check, but only on >>> windows, which >>> I don't use. >>> How do I track this down? >>> The test in question works fine on my Linux box. >>> >>> Terry >>> >>> >>> >>>? ? ? ? [[alternative HTML version deleted]] >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel>>> >> ??? [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >>??? [[alternative HTML version deleted]] ______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 3/5/20 5:39 PM, Therneau, Terry M., Ph.D. via R-devel wrote:> ?I ended up finding the issue by a focused code review. > > Once in the past, I had a version that would fail under one architecture but not another, > in that case some help from Brian Ripley pointed me to the offending line of C code. > That line read, but did not write, at an invalid memory location.?? Starting with the > question of "what C routines have I added or modified most recently" along with where the > fault appeared to occur in my test suite, I started reading C code and found one. > Revised code passes tests on the winbuilder site. > > For the curious, I had a line asking "is this patient id different than the last patient > id" in the C routine underneath survcheck(); I'm making sure that patients don't go > backwards in time. Essentially > ?for (i=0; i< n; i) { > ? ?? if (id[i] != id[i-1] )? { ...} > > It is still a surprise to me that just LOOKING at this out of range element would cause a > failure,? [i-1] never appears on the left hand side of any expressions in the ... chunk > above. Nevertheless, it was an error. ? Que sera seraIn principle out of bounds access to an array, even reading, may not only return any value that may be there, but cause a memory protection failure (the memory there is not accessible) or have some other impact. Reads from memory can also have side effects (other than crashing your process). Tomas> > A strong thanks to those who gave solid suggestions for bringing up a local copy of Windows. > > Terry T > >>>> My latest submission of survival3.1-10 to CRAN fails a check, but only on >>>> windows, which >>>> I don't use. >>>> How do I track this down? >>>> The test in question works fine on my Linux box. >>>> >>>> Terry >>>> >>>> >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> [[alternative HTML version deleted]] >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel