Andrei Alexandrescu wrote:
> Great, thanks. In the meantime, unfortunately std.datetime breaks Phobos unittests at least on OSX with an internal error message:
>
> Internal error: backend/cod2.c 4530
>

That's most peculiar, as there is no assert anywhere near that line in cod2.c

On Sunday 16 January 2011 17:43:35 Jonathan M Davis wrote:
> On Sunday 16 January 2011 11:48:36 Walter Bright wrote:
> > Jonathan M Davis wrote:
> > > Regardless, there will be one function - the version std.file.lastModified which just takes the file name - which will break the build of anyone using it, because the only thing changing in its signature is its return type (SysTime instead of d_time), so there's no way to overload it. Fortunately, however, I think that it's the only function in that boat.
> > 
> > It needs to have a different name if its return type changes.
> 
> Okay, then. If that's how you'd prefer to do it, then I guess that that's what I'll do - though nothing immediately comes to mind as an alternate name for lastModified. I'll have to brainstorm a bit, I guess.

LOL. Oh, how life gets more interesting. Not only is there also creationTime, lastAccessTime, and lastWriteTime in DirEntry which must be renamed, but in trying to find new names for them, I figured out that creationTime is totally wrong on Posix systems. We've been using stat's st_ctime as the creationTime, but it _isn't_ the creation time. It's the last time that the _file status_ changed  (i.e., owner, group, link count, mode, etc.). stat doesn't _give_ a creation time. So, creationTime doesn't actually make any sense on Posix systems. LOL. Ouch.

Well, since I have to rename them anyway, it's the perfect time to set creationTime down the path of deprecation on Posix systems. I guess that I'll add the status change property (whatever I end up calling it) to the Posix side as a replacement. Bleh. I was already planning to make some changes some time soon from a patch I've had for a while which fixes the lack of symlink support, but the more I look at the file stuff, the more stuff that I see pop up which is system-specific. *Sigh* Such is life I suppose.

- Jonathan M Davis

What about including a private module std.dtdeprecated that prints the message?  Then at least you can cut it down to one message, no matter  how many modules you import.

-Steve



----- Original Message ----
> From: Jonathan M Davis <jmdavisProg at gmx.com>
> To: phobos at puremagic.com
> Sent: Sun, January 16, 2011 12:00:34 AM
> Subject: Re: [phobos] Deprecation of std.date
> 
> On Saturday 15 January 2011 20:48:01 Walter Bright wrote:
> > Jonathan M  Davis wrote:
> > > are we willing to have the build output  flooded
> > > with "scheduled for deprecation" messages for a release or  two?
> > 
> > We already have some of those, and it's not a  problem.
> 
> The problem is that it's very nearly _every other  line_:

On Monday, January 17, 2011 05:47:02 Steve Schveighoffer wrote:
> What about including a private module std.dtdeprecated that prints the message?  Then at least you can cut it down to one message, no matter  how many modules you import.

When compiling phobos normally, the message only prints once. It's only when building phobos with the unit tests enabled that it gets printed over and over. I get the impression that each module is built and run separately when building and running the unit tests on Linux. If that is indeed the case, then your suggestion doesn't really help, since the problem isn't that the deprecated modules get imported multiple times but rather that they're included in multiple builds.

- Jonathan M Davis

Jonathan M Davis wrote:
> When compiling phobos normally, the message only prints once. It's only when building phobos with the unit tests enabled that it gets printed over and over. I get the impression that each module is built and run separately when building and running the unit tests on Linux.

Your impression is correct.

>  If that is indeed the case, then your
> suggestion doesn't really help, since the problem isn't that the deprecated
> modules get imported multiple times but rather that they're included in multiple
> builds.
>
> 

I meant to avoid seeing e.g. two separate messages for std.date and std.dateparse

-Steve

Sent from my iPhone

On Jan 17, 2011, at 12:24 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Monday, January 17, 2011 05:47:02 Steve Schveighoffer wrote:
>> What about including a private module std.dtdeprecated that prints the message?  Then at least you can cut it down to one message, no matter  how many modules you import.
> 
> When compiling phobos normally, the message only prints once. It's only when building phobos with the unit tests enabled that it gets printed over and over. I get the impression that each module is built and run separately when building and running the unit tests on Linux. If that is indeed the case, then your suggestion doesn't really help, since the problem isn't that the deprecated modules get imported multiple times but rather that they're included in multiple builds.
> 
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Monday 17 January 2011 16:35:13 Steven Schveighoffer wrote:
> I meant to avoid seeing e.g. two separate messages for std.date and std.dateparse

Good point. Though actually, now that I think about it, std.date and std.dateparse import each other, so a pragma message in one of them would likely work just fine. You'd get it whether you tried to use std.date or std.dateparse. However, if they weren't importing each other, then creating another module for the deprecation message would make good sense.

- Jonathan M Davis