www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Are these (known) bugs?

reply biozic <dransic free.fr> writes:
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
Jan 28 2011
next sibling parent biozic <dransic free.fr> writes:
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.
Jan 28 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 28 2011
parent biozic <dransic free.fr> writes:
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! :)
Jan 29 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 28 2011
parent biozic <dransic free.fr> writes:
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
Jan 28 2011