Hi,

I am playing with the to-be-released std.datetime, and encountered these errors (the last one concerns std.variant, actually), with dmd 2.052 (Mac OS X 10.6):

---
import std.array, std.datetime, std.variant;

unittest {
    auto app = appender!(Interval!Date[]);
    auto interval = Interval!Date(Date(2000, 1, 1), Date(2011, 2, 3));
    app.put(interval);
    // Error: datetime.d(20208): Invariant Failure: begin is not before or equal to end.
}

unittest {
    Variant[] va;
    ubyte u = 0;
    va ~= u;
    // Error: cannot append type ubyte to type VariantN!(maxSize)[]
}
---

Are these (known) bugs, or do I do anything wrong?
Thanks,
Nicolas

Le 28/01/11 19:57, biozic a écrit :
> unittest {
>     Variant[] va;
>     ubyte u = 0;
>     va ~= u;
>     // Error: cannot append type ubyte to type VariantN!(maxSize)[]
> }

Hmm... I'm silly, forget this one :)
va ~= Variant(u), of course.

On Friday, January 28, 2011 10:57:58 biozic wrote:
> Hi,
> 
> I am playing with the to-be-released std.datetime, and encountered these
> errors (the last one concerns std.variant, actually), with dmd 2.052
> (Mac OS X 10.6):
> 
> ---
> import std.array, std.datetime, std.variant;
> 
> unittest {
>      auto app = appender!(Interval!Date[]);
>      auto interval = Interval!Date(Date(2000, 1, 1), Date(2011, 2, 3));
>      app.put(interval);
>      // Error: datetime.d(20208): Invariant Failure: begin is not before
> or equal to end.
> }

There no known bugs in std.datetime. My guess would be that the issue lies with appender and Interval!(Date).init and/or something set to void if appender does that at all. But since Date.init would be equal to Date.init, it seems extremely bizarre that Interval!(Date).init would have its begin and end not be equal, which makes it less likely that Interval!(Date).init would be the problem. So, I don't know. The code is very thoroughly tested, but that doesn't mean that I didn't miss something, and it's possible that there's a bug in appender. I'm not at all familiar with how appender works. I'll have to take a look at it tonight.

But std.datetime has a ton of unit tests and, as far as I know, is currently passing all of them on Linux, Windows, and OS X (I don't know about FreeBSD). The most likely problems would be on OS X or FreeBSD, since I don't have a system with either OS X or FreeBSD, and there could be problems in time zones other than America/Los_Angeles - particularly on Windows where you can't easily test time zones other than the one that you're in - since all of my development has been done in America/Los_Angeles. But I'm not aware of any bugs. So, if you do find problems, please report them.

- Jonathan M Davis

On Friday 28 January 2011 13:55:03 Jonathan M Davis wrote:
> On Friday, January 28, 2011 10:57:58 biozic wrote:
> > Hi,
> > 
> > I am playing with the to-be-released std.datetime, and encountered these
> > errors (the last one concerns std.variant, actually), with dmd 2.052
> > (Mac OS X 10.6):
> > 
> > ---
> > import std.array, std.datetime, std.variant;
> > 
> > unittest {
> > 
> >      auto app = appender!(Interval!Date[]);
> >      auto interval = Interval!Date(Date(2000, 1, 1), Date(2011, 2, 3));
> >      app.put(interval);
> >      // Error: datetime.d(20208): Invariant Failure: begin is not before
> > 
> > or equal to end.
> > }
> 
> There no known bugs in std.datetime. My guess would be that the issue lies with appender and Interval!(Date).init and/or something set to void if appender does that at all. But since Date.init would be equal to Date.init, it seems extremely bizarre that Interval!(Date).init would have its begin and end not be equal, which makes it less likely that Interval!(Date).init would be the problem. So, I don't know. The code is very thoroughly tested, but that doesn't mean that I didn't miss something, and it's possible that there's a bug in appender. I'm not at all familiar with how appender works. I'll have to take a look at it tonight.
> 
> But std.datetime has a ton of unit tests and, as far as I know, is currently passing all of them on Linux, Windows, and OS X (I don't know about FreeBSD). The most likely problems would be on OS X or FreeBSD, since I don't have a system with either OS X or FreeBSD, and there could be problems in time zones other than America/Los_Angeles - particularly on Windows where you can't easily test time zones other than the one that you're in - since all of my development has been done in America/Los_Angeles. But I'm not aware of any bugs. So, if you do find problems, please report them.

Okay. This is pretty much _has_ to be either a bug in appender or in the compiler. It happens non-derministically. The exact same program will sometimes work just fine and sometimes the invariant will fail. It almost has to be the case that the values being used were initialized with garbage data. It's the kind of thing that I'd expect if = void had been used. I don't see = void in the appender code, but it _is_ calling GC functions such as GC.extend and GC.qalloc. I don't know enough about appender or how those functions work, but I suspect that something isn't being properly initialized before it's used. Open a bug report on the issue. Someone with knowledge of appender is going to have to take a look at it.

- Jonathan M Davis

Le 29/01/11 03:51, Jonathan M Davis a écrit :
> On Friday 28 January 2011 13:55:03 Jonathan M Davis wrote:
>> On Friday, January 28, 2011 10:57:58 biozic wrote:
>>> Hi,
>>>
>>> I am playing with the to-be-released std.datetime, and encountered these
>>> errors (the last one concerns std.variant, actually), with dmd 2.052
>>> (Mac OS X 10.6):
>>>
>>> ---
>>> import std.array, std.datetime, std.variant;
>>>
>>> unittest {
>>>
>>>       auto app = appender!(Interval!Date[]);
>>>       auto interval = Interval!Date(Date(2000, 1, 1), Date(2011, 2, 3));
>>>       app.put(interval);
>>>       // Error: datetime.d(20208): Invariant Failure: begin is not before
>>>
>>> or equal to end.
>>> }
>> There no known bugs in std.datetime. My guess would be that the issue lies
>> with appender and Interval!(Date).init and/or something set to void if
>> appender does that at all. But since Date.init would be equal to
>> Date.init, it seems extremely bizarre that Interval!(Date).init would have
>> its begin and end not be equal, which makes it less likely that
>> Interval!(Date).init would be the problem. So, I don't know. The code is
>> very thoroughly tested, but that doesn't mean that I didn't miss
>> something, and it's possible that there's a bug in appender. I'm not at
>> all familiar with how appender works. I'll have to take a look at it
>> tonight.
>>
>> But std.datetime has a ton of unit tests and, as far as I know, is
>> currently passing all of them on Linux, Windows, and OS X (I don't know
>> about FreeBSD). The most likely problems would be on OS X or FreeBSD,
>> since I don't have a system with either OS X or FreeBSD, and there could
>> be problems in time zones other than America/Los_Angeles - particularly on
>> Windows where you can't easily test time zones other than the one that
>> you're in - since all of my development has been done in
>> America/Los_Angeles. But I'm not aware of any bugs. So, if you do find
>> problems, please report them.
> Okay. This is pretty much _has_ to be either a bug in appender or in the
> compiler. It happens non-derministically. The exact same program will sometimes
> work just fine and sometimes the invariant will fail. It almost has to be the
> case that the values being used were initialized with garbage data. It's the
> kind of thing that I'd expect if = void had been used. I don't see = void in the
> appender code, but it _is_ calling GC functions such as GC.extend and GC.qalloc.
> I don't know enough about appender or how those functions work, but I suspect
> that something isn't being properly initialized before it's used. Open a bug
> report on the issue. Someone with knowledge of appender is going to have to take
> a look at it.
>
> - Jonathan M Davis

Thanks for your answer. Indeed, the bug might concern garbage-initialized structs during appending. It is reducible to:

---
import std.array;

struct Foo {
    int a, b;

    Foo opAssign(Foo rhs) {
        a = rhs.a;
        b = rhs.b;
        return this;
    }

    invariant () {
        assert (a <= b);
    }
}

unittest {
    auto app = appender!(Foo[]);
    auto foo = Foo(1, 2);
    app.put(foo);
}
---

It involves calling an invariant() on a struct where opAssign is overloaded. You have filed a report concerning such a problem in issue #5058.

Le 28/01/11 22:55, Jonathan M Davis a écrit :
> On Friday, January 28, 2011 10:57:58 biozic wrote:
>> Hi,
>>
>> I am playing with the to-be-released std.datetime, and encountered these
>> errors (the last one concerns std.variant, actually), with dmd 2.052
>> (Mac OS X 10.6):
>>
>> ---
>> import std.array, std.datetime, std.variant;
>>
>> unittest {
>>       auto app = appender!(Interval!Date[]);
>>       auto interval = Interval!Date(Date(2000, 1, 1), Date(2011, 2, 3));
>>       app.put(interval);
>>       // Error: datetime.d(20208): Invariant Failure: begin is not before
>> or equal to end.
>> }
> There no known bugs in std.datetime. My guess would be that the issue lies with
> appender and Interval!(Date).init and/or something set to void if appender does
> that at all. But since Date.init would be equal to Date.init, it seems extremely
> bizarre that Interval!(Date).init would have its begin and end not be equal,
> which makes it less likely that Interval!(Date).init would be the problem. So, I
> don't know. The code is very thoroughly tested, but that doesn't mean that I
> didn't miss something, and it's possible that there's a bug in appender. I'm not
> at all familiar with how appender works. I'll have to take a look at it tonight.
>
> But std.datetime has a ton of unit tests and, as far as I know, is currently
> passing all of them on Linux, Windows, and OS X (I don't know about FreeBSD).
> The most likely problems would be on OS X or FreeBSD, since I don't have a
> system with either OS X or FreeBSD, and there could be problems in time zones
> other than America/Los_Angeles - particularly on Windows where you can't easily
> test time zones other than the one that you're in - since all of my development
> has been done in America/Los_Angeles. But I'm not aware of any bugs. So, if you
> do find problems, please report them.
>
> - Jonathan M Davis

I could not use an Interval in a Variant, because Interval defines a length property which does not return a size_t value, and Variant does not handle it (I have filed a report about this).

Not only the ton of unit tests in std.datetime appears to make it rock-solid, but it seems it is also a good test case for other standard modules! :)