In principle I agree that this would be the tidiest solution. But considering the size of the date/time modules that have been proposed (and those aren't even complete yet), I fear std.datetime will be huge.

How about keeping std.date and introducing std.time?

Anyway, if there is agreement on a solution, I can take care of moving stuff around tomorrow - tonight for most of you, that is - if nobody beats me to it.

-Lars

----- Reply message -----
From: "Andrei Alexandrescu" <andrei at erdani.com>
Date: Thu, Sep 9, 2010 16:08
Subject: [phobos] next release
To: "Discuss the phobos library for D" <phobos at puremagic.com>

On 9/9/10 8:20 CDT, Lars Tandle Kyllingstad wrote:
> I think we should make some kind of decision regarding the date/time module(s) before releasing a Phobos version that contains std.stopwatch.
>
> It would be silly to introduce a new module, only to deprecate it and move Stopwatch into std.time (or whatever) in the following release...

Oh, I forgot that hasn't been resolved. Let's do this:

1. deprecate std.perf

2. Define std.datetime, paste std.stopwatch in it, and have it import std.date for now

3. Put a reminding comment in std.date that it'll be deprecated in favor of std.datetime

Does someone have the time to do so today?


Andrei
_______________________________________________
phobos mailing list
phobos at puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100909/693ca105/attachment.html>

Could we not put a warning in std.stopwatch like:

"warning, std.stopwatch is experimental, and may change API/module name"

I personally think std.datetime makes the most sense (with everything).  But clearly, an 11th hour decision without consensus or a complete implementation may not be the best idea.  Locking ourselves into something without knowing what it's going to look like doesn't make any sense to me.

-Steve

________________________________
From: Lars Tandle Kyllingstad <lars at kyllingen.net>
To: Discuss the phobos library for D <phobos at puremagic.com>
Sent: Thu, September 9, 2010 5:18:01 PM
Subject: Re: [phobos] next release

In principle I agree that this would be the tidiest solution. But considering the size of the date/time modules that have been proposed (and those aren't even

complete yet), I fear std.datetime will be huge.

How about keeping std.date and introducing std.time?

Anyway, if there is agreement on a solution, I can take care of moving stuff around tomorrow - tonight for most of you, that is - if nobody beats me to it.

-Lars

----- Reply message -----
From: "Andrei Alexandrescu" <andrei at erdani.com>
Date: Thu, Sep 9, 2010 16:08
Subject: [phobos] next release
To: "Discuss the phobos library for D" <phobos at puremagic.com>

On 9/9/10 8:20 CDT, Lars Tandle Kyllingstad wrote:
> I think we should make some kind of decision regarding the date/time module(s) before releasing a Phobos version that contains std.stopwatch.
>
> It would be silly to introduce a new module, only to deprecate it and move Stopwatch into std.time (or whatever) in the following release...

Oh, I forgot that hasn't been resolved. Let's do this:

1. deprecate std.perf

2. Define std.datetime, paste std.stopwatch in it, and have it import std.date for now

3. Put a reminding comment in std.date that it'll be deprecated in favor of std.datetime

Does someone have the time to do so today?


Andrei
_______________________________________________
phobos mailing list
phobos at puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 9/9/10 16:27 CDT, Steve Schveighoffer wrote:
> Could we not put a warning in std.stopwatch like:
>
> "warning, std.stopwatch is experimental, and may change API/module name"

No please.

> I personally think std.datetime makes the most sense (with everything).  But clearly, an 11th hour decision without consensus or a complete implementation may not be the best idea.  Locking ourselves into something without knowing what it's going to look like doesn't make any sense to me.

Then let's have std.stopwatch wait one more release cycle.


Andrei

Alternatively, we can have std.stopwatch not appear in the docs until we are certain of its location.

I think not including it is not a good idea.  Going by that philosophy, we will have to wait until all date/time stuff is done before it's included.

Another alternative is to call it std.xstopwatch until it's not experimental anymore.  At least it will be easy to search/replace later.

Basically what we need is a mechanism to convey to the user that things aren't set in stone for stopwatch.  Although are we making that guarantee anywhere else?  I think through the last few releases, phobos has had breaking changes (input ranges' save function comes to mind).

-Steve



----- Original Message ----
From: Andrei Alexandrescu <andrei at erdani.com>
To: Discuss the phobos library for D <phobos at puremagic.com>
Sent: Thu, September 9, 2010 5:38:15 PM
Subject: Re: [phobos] next release

On 9/9/10 16:27 CDT, Steve Schveighoffer wrote:
> Could we not put a warning in std.stopwatch like:
>
> "warning, std.stopwatch is experimental, and may change API/module name"

No please.

> I personally think std.datetime makes the most sense (with everything).  But clearly, an 11th hour decision without consensus or a complete implementation may not be the best idea.  Locking ourselves into something without knowing
>what
> it's going to look like doesn't make any sense to me.

Then let's have std.stopwatch wait one more release cycle.


Andrei
_______________________________________________
phobos mailing list
phobos at puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 9/9/10 16:47 CDT, Steve Schveighoffer wrote:
> Alternatively, we can have std.stopwatch not appear in the docs until we are certain of its location.

Then why add it? Most surely there won't be a module std.stopwatch.

> I think not including it is not a good idea.  Going by that philosophy, we will have to wait until all date/time stuff is done before it's included.

I'm talking about a minor release - a month.

> Another alternative is to call it std.xstopwatch until it's not experimental anymore.  At least it will be easy to search/replace later.
>
> Basically what we need is a mechanism to convey to the user that things aren't set in stone for stopwatch.  Although are we making that guarantee anywhere else?  I think through the last few releases, phobos has had breaking changes (input ranges' save function comes to mind).

std.stopwatch is a simple artifact with a simple charter. I don't think we need to overengineer this.


Andrei

On Thursday 09 September 2010 15:12:56 Andrei Alexandrescu wrote:
> On 9/9/10 16:47 CDT, Steve Schveighoffer wrote:
> > Alternatively, we can have std.stopwatch not appear in the docs until we are certain of its location.
> 
> Then why add it? Most surely there won't be a module std.stopwatch.
> 
> > I think not including it is not a good idea.  Going by that philosophy, we will have to wait until all date/time stuff is done before it's included.
> 
> I'm talking about a minor release - a month.
> 
> > Another alternative is to call it std.xstopwatch until it's not experimental anymore.  At least it will be easy to search/replace later.
> > 
> > Basically what we need is a mechanism to convey to the user that things aren't set in stone for stopwatch.  Although are we making that guarantee anywhere else?  I think through the last few releases, phobos has had breaking changes (input ranges' save function comes to mind).
> 
> std.stopwatch is a simple artifact with a simple charter. I don't think we need to overengineer this.
> 
> 
> Andrei

Just so you know, I fully expect that the datetime code that I've been working on will be done in less than a month. It'll be at least a week (probably closer to two), but it certainly won't be in the range of a month. Now, how many changes will be required after it's reviewed, or whether it will be accepted at all, is another matter. But it shouldn't be all that much longer before I'm done.

Personally, I don't see any problem in having stopwatch in std.datetime. My code will certainly make for a large module in terms of the number of bytes that it is, but a large portion of that is unit tests and documentation. I would fully expect that in the long run other modules such as std.container will be far larger in terms of the number of types and functions in it (I have no idea about the size of the file though - I have a lot of unit tests). I would expect that stopwatch could fit in there just fine. Certainly, I don't see anywhere is that it's going to go under the current scheme.

It may be, however, that we're going to have to break down and allow some sort of package hierarchy at some point rather than having everything directly in std. Still, I don't know that we'd want a module like stopwatch which is essentially for one struct. If we end up with many single-purpose modules like that though, I think that we're definitely going to want some sort of module hierchary for at least some of them.

Regardless, I'd say that we want to avoid creating modules - or any code in general for that matter - which is not likely to stick around for long. It would likely be better practice to either figure out exactly where it's going to go and put it there or to simply have it not listed in the online docs until it is where it's likely to be permanently.

- Jonathan M Davis

On Thu, 09 Sep 2010 19:25:26 -0500, Jonathan M Davis <jmdavisprog at gmail.com> wrote:

> [snip]

Hi Jonathan.

I recently came across to this bug report you did about adding more comprehensive unit testing functions:

> http://d.puremagic.com/issues/show_bug.cgi?id=4653

The thing is, I did something similar to unit test my Boost date time library. I have a module with a few unit testing methods, similar in name to the JUnit library:

> http://bitbucket.org/gomez/yao-library/src/tip/src/yao/unittesting/assertions.d

Unfortunately, my asserEquals function is almost the same as yours. I just wanted to let you know that I didn't stole from your module. :) However, if you think that is too similar, I can give you some attribution. I just don't want another licencing issue like the Tango affair.

By the way, I have completed, some days ago, the time module from the Boost datetime library port. The only missing component is LocalDate and all the TimeZone paraphernalia:

> http://bitbucket.org/gomez/yao-library/src/tip/src/yao/datetime/core.d http://bitbucket.org/gomez/yao-library/src/tip/src/yao/datetime/date.d http://bitbucket.org/gomez/yao-library/src/tip/src/yao/datetime/time.d

The yao.datetime.time module lacks unittesting and documentation, but I'm working on that.


-- 
Yao G.

On Thursday 09 September 2010 18:44:23 Yao G. wrote:
> On Thu, 09 Sep 2010 19:25:26 -0500, Jonathan M Davis
> 
> <jmdavisprog at gmail.com> wrote:
> > [snip]
> 
> Hi Jonathan.
> 
> I recently came across to this bug report you did about adding more
> 
> comprehensive unit testing functions:
> > http://d.puremagic.com/issues/show_bug.cgi?id=4653
> 
> The thing is, I did something similar to unit test my Boost date time library. I have a module with a few unit testing methods, similar in name
> 
> to the JUnit library:
> > http://bitbucket.org/gomez/yao-library/src/tip/src/yao/unittesting/assert ions.d
> 
> Unfortunately, my asserEquals function is almost the same as yours. I just wanted to let you know that I didn't stole from your module. :) However, if you think that is too similar, I can give you some attribution. I just don't want another licencing issue like the Tango affair.

I've used similar functions in both JUnit and cppunit. They're pretty standard. Don't worry about it. I do think that we need some functions like that in Phobos, however.

> 
> By the way, I have completed, some days ago, the time module from the Boost datetime library port. The only missing component is LocalDate and
> 
> all the TimeZone paraphernalia:
> > http://bitbucket.org/gomez/yao-library/src/tip/src/yao/datetime/core.d http://bitbucket.org/gomez/yao-library/src/tip/src/yao/datetime/date.d http://bitbucket.org/gomez/yao-library/src/tip/src/yao/datetime/time.d
> 
> The yao.datetime.time module lacks unittesting and documentation, but I'm working on that.

It's precisely the time zone stuff which is going to make make me take at least another week (that and other stuff in life that I need to deal with). If it weren't for that, then I'd probably done in a day or two. However, I'm _very_ interested in getting that into Phobos, so I'm definitely doing it.

- Jonathan M Davis

On 9 September 2010 23:38, Andrei Alexandrescu <andrei at erdani.com> wrote:
> On 9/9/10 16:27 CDT, Steve Schveighoffer wrote:
>>
>> Could we not put a warning in std.stopwatch like:
>>
>> "warning, std.stopwatch is experimental, and may change API/module name"
>
> No please.
>
>> I personally think std.datetime makes the most sense (with everything).
>> ?But
>> clearly, an 11th hour decision without consensus or a complete
>> implementation
>> may not be the best idea. ?Locking ourselves into something without
>> knowing what
>> it's going to look like doesn't make any sense to me.
>
> Then let's have std.stopwatch wait one more release cycle.

Four days later --
I've just looked at the Phobos source, and std.stopwatch is still in there!!!!
There's no more time for discussion on naming, it'll have to wait
until the next release.
Please somebody, pull it from this release NOW so that we can release a beta.

Here be a showstopper Phobos regression related to Zip plus sort.  IMHO we should not release until this is fixed.

http://d.puremagic.com/issues/show_bug.cgi?id=4861
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100913/6943895f/attachment-0001.html>