phobos commit, revision 2319


user: jmdavis

msg:
New std.datetime added.

Nothing in Phobos has been made to use it yet and nothing has yet been marked as deprecated or scheduled for deprecation due to the new std.datetime being checked in. That's for a future commit.

http://www.dsource.org/projects/phobos/changeset/2319

paths changed:
U   trunk/phobos/phobos.d
U   trunk/phobos/std/datetime.d
U   trunk/phobos/std.ddoc

On Wednesday 12 January 2011 01:13:54 dsource.org wrote:
> phobos commit, revision 2319
> 
> 
> user: jmdavis
> 
> msg:
> New std.datetime added.
> 
> Nothing in Phobos has been made to use it yet and nothing has yet been marked as deprecated or scheduled for deprecation due to the new std.datetime being checked in. That's for a future commit.
> 
> http://www.dsource.org/projects/phobos/changeset/2319
> 
> paths changed:
> U   trunk/phobos/phobos.d
> U   trunk/phobos/std/datetime.d
> U   trunk/phobos/std.ddoc
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Okay. The new std.datetime is in. I updated the documention stuff so that it should actually end up in the docs now (assuming that I did it correctly), but I haven't yet gone and made anything else (such as std.file.lastModified) use it yet, and I haven't yet marked anything as deprecated or scheduled for deprecation due to the new std.datetime getting checked in.

I'll try and look at adjusting the other modules in Phobos to use std.datetime tomorrow evening, at which point I'll likely mark std.date as scheduled for deprecation in its documentation. Given what happened with Andrei's last round of deprecating stuff, I'm not sure that it would be a good idea to actually mark std.date as deprecated yet though. In any case, I'll get the other modules to use std.datetime instead of std.date relatively soon.

Hopefully, there are no suprises with tests on Windows failing or whatnot. Brad's had enough of that for a while, I think.

- Jonathan M Davis

On 1/12/2011 1:22 AM, Jonathan M Davis wrote:
> On Wednesday 12 January 2011 01:13:54 dsource.org wrote:
>> phobos commit, revision 2319
>>
>>
>> user: jmdavis
>>
>> msg:
>> New std.datetime added.
>>
>> Nothing in Phobos has been made to use it yet and nothing has yet been marked as deprecated or scheduled for deprecation due to the new std.datetime being checked in. That's for a future commit.
>>
>> http://www.dsource.org/projects/phobos/changeset/2319
>>
>> paths changed:
>> U   trunk/phobos/phobos.d
>> U   trunk/phobos/std/datetime.d
>> U   trunk/phobos/std.ddoc
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> Okay. The new std.datetime is in. I updated the documention stuff so that it should actually end up in the docs now (assuming that I did it correctly), but I haven't yet gone and made anything else (such as std.file.lastModified) use it yet, and I haven't yet marked anything as deprecated or scheduled for deprecation due to the new std.datetime getting checked in.
> 
> I'll try and look at adjusting the other modules in Phobos to use std.datetime tomorrow evening, at which point I'll likely mark std.date as scheduled for deprecation in its documentation. Given what happened with Andrei's last round of deprecating stuff, I'm not sure that it would be a good idea to actually mark std.date as deprecated yet though. In any case, I'll get the other modules to use std.datetime instead of std.date relatively soon.
> 
> Hopefully, there are no suprises with tests on Windows failing or whatnot. Brad's had enough of that for a while, I think.
> 
> - Jonathan M Davis

The new module will need to be added to the two .mak files before it'll be properly built and tested.  Pick a previously existing module and use it as a pattern to follow.  The two files are very different.

I expect fallout from a new file and a bunch of new code.. it's pretty much inevitable.  The core.time module exposed 4 new bugs in the 64 bit code gen, but Walter and I got 'em isolated and fixed in fairly short order.

Thanks for the hard work.

Later,
Brad

On Wednesday 12 January 2011 01:28:07 Brad Roberts wrote:
> The new module will need to be added to the two .mak files before it'll be properly built and tested.  Pick a previously existing module and use it as a pattern to follow.  The two files are very different.

??? It was already in the mak files from the previous version. Or is there somewhere in there that it wasn't? It does build as part of the build if I run make -f posix.mak.

> I expect fallout from a new file and a bunch of new code.. it's pretty much inevitable.  The core.time module exposed 4 new bugs in the 64 bit code gen, but Walter and I got 'em isolated and fixed in fairly short order.
> 
> Thanks for the hard work.

Well, breaking 64-bit stuff is a bit different from having tests fail on Windows due to platform differences. Last time I ran the tests with wine though, they passed. Of course, the core.time tests did too, and they ended up failing on an actual Windows box, so go figure.

It's a lot of code though, so it wouldn't surprise me at all if it the 64-bit stuff didn't handle it very well. The more code you're dealing with, the more likely you are to find a bug. I certainly found plenty of them while implementing it - just not in the 64-bit compiler, because I haven't done anything with that.

- Jonathan M Davis

On 1/12/2011 1:35 AM, Jonathan M Davis wrote:
> On Wednesday 12 January 2011 01:28:07 Brad Roberts wrote:
>> The new module will need to be added to the two .mak files before it'll be properly built and tested.  Pick a previously existing module and use it as a pattern to follow.  The two files are very different.
> 
> ??? It was already in the mak files from the previous version. Or is there somewhere in there that it wasn't? It does build as part of the build if I run make -f posix.mak.

Sorry, thought it was brand new, meaning it wasn't there yet.

>> I expect fallout from a new file and a bunch of new code.. it's pretty much inevitable.  The core.time module exposed 4 new bugs in the 64 bit code gen, but Walter and I got 'em isolated and fixed in fairly short order.
>>
>> Thanks for the hard work.
> 
> Well, breaking 64-bit stuff is a bit different from having tests fail on Windows due to platform differences. Last time I ran the tests with wine though, they passed. Of course, the core.time tests did too, and they ended up failing on an actual Windows box, so go figure.
> 
> It's a lot of code though, so it wouldn't surprise me at all if it the 64-bit stuff didn't handle it very well. The more code you're dealing with, the more likely you are to find a bug. I certainly found plenty of them while implementing it - just not in the 64-bit compiler, because I haven't done anything with that.

We'll find out.

On Wednesday 12 January 2011 01:48:00 Brad Roberts wrote:
> On 1/12/2011 1:35 AM, Jonathan M Davis wrote:
> > On Wednesday 12 January 2011 01:28:07 Brad Roberts wrote:
> >> The new module will need to be added to the two .mak files before it'll be properly built and tested.  Pick a previously existing module and use it as a pattern to follow.  The two files are very different.
> > 
> > ??? It was already in the mak files from the previous version. Or is there somewhere in there that it wasn't? It does build as part of the build if I run make -f posix.mak.
> 
> Sorry, thought it was brand new, meaning it wasn't there yet.

Well, almost none of the code is the same, but the module was already there.

> >> I expect fallout from a new file and a bunch of new code.. it's pretty much inevitable.  The core.time module exposed 4 new bugs in the 64 bit code gen, but Walter and I got 'em isolated and fixed in fairly short order.
> >> 
> >> Thanks for the hard work.
> > 
> > Well, breaking 64-bit stuff is a bit different from having tests fail on Windows due to platform differences. Last time I ran the tests with wine though, they passed. Of course, the core.time tests did too, and they ended up failing on an actual Windows box, so go figure.
> > 
> > It's a lot of code though, so it wouldn't surprise me at all if it the 64-bit stuff didn't handle it very well. The more code you're dealing with, the more likely you are to find a bug. I certainly found plenty of them while implementing it - just not in the 64-bit compiler, because I haven't done anything with that.
> 
> We'll find out.

Well, the autotester appears to be failing on checkout of all things. I guess it's because dsource is down at the moment. So, if there are any problems with the new code, I'll have to fix them tomorrow, since I'm heading to bed...

- Jonathan M Davis

Well, the Phobos unittest build continues to fail by running out of memory. I'm really quite stumped by it. Running it in Linux, I don't think that it ever goes much above 100MB, and most of the time, its memory consumption is considerably less. However, on Windows, it goes above 900MB and decides that its run out of memory.

The problem does appear to be in std.datetime, since if I comment out the module, it's fine. If I comment out a large portion of the unit tests, it's fine, but I get the impression that it's due to the large number of unit tests rather than any particular test. Maybe  it's due to the templated test functions I'm using taking up too much memory which isn't released? There _is_ at least one bug relating to memory not being released during CTFE.

However, to make matters even more interesting, when I ran the unittest build in wine, it didn't have any memory problems. I think that it might have hit around 300MB, which is more than the Linux build got to, but it certainly wasn't in excess of 900MB. So, I'm rather stumped as to what to do about it.

- Jonathan M Davis

PLEASE comment out the failing tests while you work on it. Reason
being, that it means that other people cannot tell if a change they've
checked in has broken the tests. This affects Phobos, druntime, and
the compiler. You should take the view that all development is blocked
while it's broken.
It is OK to break the tests (it would be useless if it never failed!)
But if it fails, get it working again ASAP by whatever means necessary
(including reverting the commit, or in the worst case, commenting out
tests).



On 13 January 2011 08:52, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> Well, the Phobos unittest build continues to fail by running out of memory. I'm really quite stumped by it. Running it in Linux, I don't think that it ever goes much above 100MB, and most of the time, its memory consumption is considerably less. However, on Windows, it goes above 900MB and decides that its run out of memory.
>
> The problem does appear to be in std.datetime, since if I comment out the module, it's fine. If I comment out a large portion of the unit tests, it's fine, but I get the impression that it's due to the large number of unit tests rather than any particular test. Maybe ?it's due to the templated test functions I'm using taking up too much memory which isn't released? There _is_ at least one bug relating to memory not being released during CTFE.
>
> However, to make matters even more interesting, when I ran the unittest build in wine, it didn't have any memory problems. I think that it might have hit around 300MB, which is more than the Linux build got to, but it certainly wasn't in excess of 900MB. So, I'm rather stumped as to what to do about it.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Thursday 13 January 2011 00:18:54 Don Clugston wrote:
> PLEASE comment out the failing tests while you work on it. Reason
> being, that it means that other people cannot tell if a change they've
> checked in has broken the tests. This affects Phobos, druntime, and
> the compiler. You should take the view that all development is blocked
> while it's broken.
> It is OK to break the tests (it would be useless if it never failed!)
> But if it fails, get it working again ASAP by whatever means necessary
> (including reverting the commit, or in the worst case, commenting out
> tests).

Okay. Will do. I don't know why that didn't occur to me. Sorry about that.

That's going to be a bit of a pain since it's not that the tests are failing but rather that the compilation is just running out of memory, so I'm pretty much going to have to comment out a large portion of them one by one. But I'll make a stab at it.

- Jonathan M Davis

On Thursday 13 January 2011 00:47:37 Jonathan M Davis wrote:
> On Thursday 13 January 2011 00:18:54 Don Clugston wrote:
> > PLEASE comment out the failing tests while you work on it. Reason
> > being, that it means that other people cannot tell if a change they've
> > checked in has broken the tests. This affects Phobos, druntime, and
> > the compiler. You should take the view that all development is blocked
> > while it's broken.
> > It is OK to break the tests (it would be useless if it never failed!)
> > But if it fails, get it working again ASAP by whatever means necessary
> > (including reverting the commit, or in the worst case, commenting out
> > tests).
> 
> Okay. Will do. I don't know why that didn't occur to me. Sorry about that.
> 
> That's going to be a bit of a pain since it's not that the tests are failing but rather that the compilation is just running out of memory, so I'm pretty much going to have to comment out a large portion of them one by one. But I'll make a stab at it.

To save time, I just versioned the whole module as Posix for the moment. I'll re-enable it for Windows once I've had time to individually disable the unit tests for Windows or managed to figure out why on earth its using so much memory. But it seems to me that it pretty much has to be a compiler bug of some kind that its eating up memory like that _while compiling_, so I'm not really sure what I'm going to do about it. If I'm lucky, I'll be able to figure out an appropriately small test case which shows the problem, but I think that it's the sheer amount of test code which is the issue (or something in the test code, which adds up when you have that much), so creating a smaller test case won't necessarily be particularly feasible.

- Jonathan M Davis