[D-runtime] druntime commit, revision 494

Jonathan M Davis jmdavisProg at gmx.com
Mon Jan 10 10:35:50 PST 2011


On Monday, January 10, 2011 10:06:31 Brad Roberts wrote:
> On 1/9/2011 6:27 PM, Jonathan M Davis wrote:
> > On Sunday 09 January 2011 16:17:29 Brad Roberts wrote:
> >> On 1/9/2011 2:49 PM, Jonathan M Davis wrote:
> >>> On Sunday 09 January 2011 11:52:09 dsource.org wrote:
> >>>> druntime commit, revision 494
> >>>> 
> >>>> 
> >>>> user: Don Clugston
> >>>> 
> >>>> msg:
> >>>> Removed usage of Phobos in druntime, which is causing the Windows
> >>>> build to break. As far as I can tell, the error message will only
> >>>> occur on PCs *earlier* than the AT !!!! So it's not worth trying to
> >>>> make a nice error message.
> >>> 
> >>> Sorry about that. I'm not sure if it was me or SHOO who added that
> >>> check, but I didn't catch the fact that it was using std when I moved
> >>> it out of std.datetime. Shame on me.
> >>> 
> >>> I think that pretty much all of the cases where something like that
> >>> might fail is checked though, even if it really shouldn't ever happen.
> >>> 
> >>> - Jonathan M Davis
> >> 
> >> There's still at least one core.time related failure that needs to be
> >> investigated and fixed.  Win32 is failing on one of the unit tests:
> >> 
> >> core.exception.AssertError at core.time(1504): unittest failure
> >> 
> >> http://d.puremagic.com/test-results/test_data.ghtml?dataid=37612
> > 
> > Bleh. Whatever the system clocks ticks per second are on that system,
> > it's apparently not managing to hold 10_000_000 hnsecs accurately. I
> > suppose that the asserts on 1504 and 1506 will have to be made to use <=
> > instead of ==, at least for the moment. I expect that that would fix
> > them. Still, this variance in precision and the fact that Windows
> > doesn't appear to have anything approaching a round or consistent
> > (across systems anyway) number of ticks per second is definitely
> > annoying when it comes to crafting appropriate tests.
> > 
> > - Jonathan M Davis
> 
> I'd be surprised if it was unique to that box.  Add printfs if you need to
> gather data from it's test runs.  But I'd really like to come home from
> work tonight to a fully green set of testers.  It's been broken in one way
> or another since friday.

Oh, I'm not saying that it's unique to that box, rather that it appears that it 
varies from box to box. I haven't seen the problem in wine, for instance, even 
though I get a really weird number for ticksPerSec. I can't readily test it in 
Windows itself at the moment, however. I'd fix it myself, but I don't have commit 
access at the moment. I asked Sean to give me commit access, and he agreed, but 
last time I checked, he hadn't done it yet. As far as I'm concerned though, if 
you want to just comment out the asserts on lines 1504 and 1506 of time.d for 
the moment, that's fine. The functionality should be fine. I just need to figure 
out how to write more robust tests to replace them.

- Jonathan M Davis


More information about the D-runtime mailing list