Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.125.1289018234.21107.digitalmar...@puremagic.com...
I'm proposing a possible new module for phobos which would be called
std.unittests. The code and DDoc file can be found here:
http://is.gd/gLH9Q
Or you can look at the code
On Fri, 05 Nov 2010 23:13:44 -0600
Rainer Deyke rain...@eldwood.com wrote:
On 11/5/2010 17:41, Walter Bright wrote:
In other words, I create an array that I mean to fill in later, because
I don't have meaningful data for it in advance.
That's a faulty idiom. A data structure that exists
Pelle Månsson wrote:
On 11/05/2010 08:30 PM, bearophile wrote:
Denis Koroskin:
Is anyone FORCING you to use non-nullable references?
What's the big deal?
If non-nullables are introduced in D3, then Phobos will start to use
them. So probably you can't avoid using some of them.
Bye,
On Friday 05 November 2010 22:54:20 Nick Sabalausky wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.125.1289018234.21107.digitalmar...@puremagic.com...
I'm proposing a possible new module for phobos which would be called
std.unittests. The code and DDoc file can
Michel Fortin wrote:
On 2010-11-05 23:27:28 -0400, Walter Bright newshou...@digitalmars.com
said:
Michel Fortin wrote:
There's nothing out of the array's bounds in this case. Here's what I
meant:
byte[66000]* arrayPtr = null;
byte b = (*arrayPtr)[66000-1];
I'm in the array's
Rainer Deyke wrote:
On 11/5/2010 17:41, Walter Bright wrote:
In other words, I create an array that I mean to fill in later, because
I don't have meaningful data for it in advance.
That's a faulty idiom. A data structure that exists but contains no
valid data is a bug waiting to happen - no,
On 11/6/2010 01:12, spir wrote:
On Fri, 05 Nov 2010 23:13:44 -0600 Rainer Deyke rain...@eldwood.com
wrote:
That's a faulty idiom. A data structure that exists but contains
no valid data is a bug waiting to happen - no, it /is/ a bug, even
if it does not yet manifest as incorrect observable
On 11/6/2010 02:42, Walter Bright wrote:
Adam D. Ruppe wrote:
It wasn't until I added the invariant and in/out contracts to all the
functions
asserting about null that the problem's true cause became apparent.
Couldn't this happen to you with any datum that has an unexpected value
in it?
Walter:
Suppose, for example, you are appending the numbers 1..5 to the array, and
somehow appended a 17. Many moons later, something crashes because the 17 was
out of range.
This bug doesn't happen in Ada (and Delphi), because you define a ranged
integer type like this:
subtype Small is
Walter:
An example would be the bucket array for a hash table. It starts out
initially
empty, and values get added to it. I have a hard time agreeing that such a
ubiquitous and useful data structure is a bad idiom.
I agree, there are several situations where nulls are important and very
Walter Bright newshou...@digitalmars.com wrote:
Consider non-nullable type T:
T[] a = new T[4];
As others have pointed out, this would be impossible for a proper
non-nullable type. The only ways to create an array of non-nullable
elements would be a literal, concatenation with
J. M. Berger:
sarcasm
Consider immutable type immutable T:
immutable T] a = new immutable T[4];
... time goes by ...
T[1] = foo;
T[3] = bar;
In other words I create an array that I mean to fill in later,
because I don't have meaningful data for it in advance. How do I do
Walter Bright newshou...@digitalmars.com wrote:
Adam D. Ruppe wrote:
It wasn't until I added the invariant and in/out contracts to all the
functions
asserting about null that the problem's true cause became apparent.
Couldn't this happen to you with any datum that has an unexpected value
Simen kjaeraas:
As others have pointed out, this would be impossible for a proper
non-nullable type. The only ways to create an array of non-nullable
elements would be a literal, concatenation with non-nullable elements,
or casting an existing array of nullable elements.
You do not have
bearophile bearophileh...@lycos.com wrote:
Simen kjaeraas:
Bounded!(int, 1, 5)[] myArr;
myArr ~= 1; // Compile-time error: int is not implicitly castable to
Bounded!(int, 1, 5)
myArr ~= Bounded!(int, 1, 5)( 1 ); // Works perfectly
I can't say this is a nice syntax :-)
(Isn't the implicit
Simen kjaeraas:
Not sure. This way is more explicit, and errors will be caught at
compile-time.
I see. But if a syntax is ugly and too much heavy, people (rightly) don't use
it... (This is why bounded values are good as builtins).
Bye,
bearophile
On 2010-11-06 05:37, Jonathan M Davis wrote:
I'm proposing a possible new module for phobos which would be called
std.unittests. The code and DDoc file can be found here: http://is.gd/gLH9Q
Or you can look at the code here directly (though it has poor highlighting):
http://ideone.com/EOlod
The
bearophile wrote:
J. M. Berger:
sarcasm
Consider immutable type immutable T:
immutable T] a = new immutable T[4];
... time goes by ...
T[1] = foo;
T[3] = bar;
In other words I create an array that I mean to fill in later,
because I don't have meaningful data for it in advance. How do
1. the INVENTOR of the reference concept himself admits that this is a flawed
design.
see:
http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake
2. null is an a type-system attribute, hence should be checked at compile
time and would have ZERO affect on
bearophile bearophileh...@lycos.com wrote:
Simen kjaeraas:
Not sure. This way is more explicit, and errors will be caught at
compile-time.
I see. But if a syntax is ugly and too much heavy, people (rightly)
don't use it... (This is why bounded values are good as builtins).
Of course.
Simen kjaeraas simen.kja...@gmail.com wrote:
bearophile bearophileh...@lycos.com wrote:
Simen kjaeraas:
Not sure. This way is more explicit, and errors will be caught at
compile-time.
I see. But if a syntax is ugly and too much heavy, people (rightly)
don't use it... (This is why
Don wrote:
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
pure int buggy() { return unstable; }
static
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse of this
is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language will
probably never change.
This is why other people and me are proposition something different.
Bye,
Jacob Carlborg:
Even though he may actually not forget a particular fact it will be
harder and harder to find the fact because of other things blocking the
way. Eventaully it will seem you have forgot the fact.
It's not a block of the way, it's the networks that accumulate noise or just
Don:
bearophile wrote:
...
http://d.puremagic.com/issues/show_bug.cgi?id=5081
As was pointed out in a recent post, the return value of a pure function
is guaranteed to be unique, so could be allowed to implictly cast to
immutable. I'm planning a patch for that soon, to see how well it
Don:
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
pure int buggy() { return unstable; }
static this() {
Does D have anything comparable to C++ references à la void
nullCheckLessFunction(const std::string notNullStr) {...} or does it only
have the equivalent of void nullCheckingRequired(const std::string*
mightByNullStr) {...}?
On Sat, 06 Nov 2010 14:06:20 +0300, Christopher Bergqvist
ch...@digitalpoetry.se wrote:
Does D have anything comparable to C++ references à la void
nullCheckLessFunction(const std::string notNullStr) {...} or does it
only
have the equivalent of void nullCheckingRequired(const std::string*
bearophile Wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse of
this is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language will
probably never change.
This is why other people and me are proposition
Sat, 06 Nov 2010 02:48:02 -0600, Rainer Deyke wrote:
On 11/6/2010 01:12, spir wrote:
On Fri, 05 Nov 2010 23:13:44 -0600 Rainer Deyke rain...@eldwood.com
wrote:
That's a faulty idiom. A data structure that exists but contains no
valid data is a bug waiting to happen - no, it /is/ a bug, even
A while ago, someone added an example with pure functions to Wikipedia's D
article:
http://en.wikipedia.org/wiki/D_(programming_language)#Functional
Someone on the talk page asked why does the program compile despite that
mySum accesses a variable in its enclosing function:
Sat, 06 Nov 2010 05:04:59 -0400, bearophile wrote:
To see an example of this, look at this useless site
I have ambivalent feelings.. you're beginning to find the joys of irony,
but losing the joys of D :) It's done awful things to me.
Sat, 06 Nov 2010 10:20:24 +0100, Simen kjaeraas wrote:
Walter Bright newshou...@digitalmars.com wrote:
Consider non-nullable type T:
T[] a = new T[4];
As others have pointed out, this would be impossible for a proper
non-nullable type. The only ways to create an array of non-nullable
Sat, 06 Nov 2010 01:54:20 -0400, Nick Sabalausky wrote:
It may require it be used like 'mixin(assert!(blah blah))', but that's a
big part of why I've been saying for a lng time that it needs to be
possible to make CTFE's intended for string mixins to be mixed in
*without* the mixin(...)
Vladimir Panteleev wrote:
A while ago, someone added an example with pure functions to Wikipedia's
D article:
http://en.wikipedia.org/wiki/D_(programming_language)#Functional
Someone on the talk page asked why does the program compile despite that
mySum accesses a variable in its
Sat, 06 Nov 2010 13:49:20 +0200, Vladimir Panteleev wrote:
A while ago, someone added an example with pure functions to Wikipedia's
D article:
http://en.wikipedia.org/wiki/D_(programming_language)#Functional
Someone on the talk page asked why does the program compile despite that
mySum
bearophile wrote:
Don:
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
pure int buggy() { return unstable; }
Sat, 06 Nov 2010 07:30:56 -0400, foobar wrote:
Disabling stuff is a BAD design and
is bug-prone. The language should be additive, i.e. I should be
writing what I want to do, NOT listing all the possible things that I
DON'T want to do.
Then why are you here?
retard wrote:
Sat, 06 Nov 2010 10:20:24 +0100, Simen kjaeraas wrote:
Walter Bright newshou...@digitalmars.com wrote:
Consider non-nullable type T:
T[] a = new T[4];
As others have pointed out, this would be impossible for a proper
non-nullable type. The only ways to create an
retard Wrote:
Sat, 06 Nov 2010 07:30:56 -0400, foobar wrote:
Disabling stuff is a BAD design and
is bug-prone. The language should be additive, i.e. I should be
writing what I want to do, NOT listing all the possible things that I
DON'T want to do.
Then why are you here?
You just
Sat, 06 Nov 2010 13:18:34 +0100, Lutger wrote:
retard wrote:
Sat, 06 Nov 2010 10:20:24 +0100, Simen kjaeraas wrote:
Walter Bright newshou...@digitalmars.com wrote:
Consider non-nullable type T:
T[] a = new T[4];
As others have pointed out, this would be impossible for a proper
On Sat, Nov 6, 2010 at 12:23 PM, Denis Koroskin 2kor...@gmail.com wrote:
On Sat, 06 Nov 2010 14:06:20 +0300, Christopher Bergqvist
ch...@digitalpoetry.se wrote:
Does D have anything comparable to C++ references à la void
nullCheckLessFunction(const std::string notNullStr) {...} or does it
bearophile Wrote:
foobar:
Any type can be wrapped by an OPTION type. trying to do the converse of
this is impractical and is bad design.
Discussing this is a waste of time now, this part of the D language will
probably never change.
This is why other people and me are proposition
steveh steve...@useshotmai.l wrote:
I've known there are hidden tradeoffs when using these 'intelligent'
types. Non-null types add terrible runtime checks everywhere. It's
simply not acceptable in a systems programming language. Operating
system kernel uses very efficient uninitialized
On 2010-11-05 21:32:47 -0400, Don nos...@nospam.com said:
The motivation for wanting to ban them is to prevent the optimiser from
generating bad code.
It seems to me that disabling pure optimizations inside 'static this()'
would be enough to prevent generating bad code. It's not like pure
steveh:
I've known there are hidden tradeoffs when using these 'intelligent' types.
Right, every design has some trade-offs.
Non-null types add terrible runtime checks everywhere.
This is not true. They may add some runtime checks, but in practice you
normally need to perform those cheeks
Don nos...@nospam.com wrote:
Pure functions are allowed to read immutable global variables.
Currently, this even includes globals which are initialized from inside
'static this()'.
Here's an example of how this can be a problem:
immutable int unstable;
pure int buggy() { return unstable; }
Walter said:
Couldn't this happen to you with any datum that has an unexpected value in it?
Yes, indeed. And being able to disable struct default constructors would (I
believe anyway) let us fix that in the library too, by forcing initialization
upon
declaration.
Right now, we could write a
Michel Fortin wrote:
On 2010-11-05 21:32:47 -0400, Don nos...@nospam.com said:
The motivation for wanting to ban them is to prevent the optimiser
from generating bad code.
It seems to me that disabling pure optimizations inside 'static this()'
would be enough to prevent generating bad code.
steveh wrote:
Non-null types add terrible runtime checks everywhere.
No they don't. They *remove* runtime checks everywhere.
There are only two possible situations for a given pointer:
1. You know that it cannot be null. In that case, you use a
non-nullable type for that pointer to
Walter Bright, el 6 de noviembre a las 01:47 me escribiste:
Rainer Deyke wrote:
On 11/5/2010 17:41, Walter Bright wrote:
In other words, I create an array that I mean to fill in later, because
I don't have meaningful data for it in advance.
That's a faulty idiom. A data structure that
Rainer Deyke wrote:
On 11/6/2010 02:42, Walter Bright wrote:
Adam D. Ruppe wrote:
It wasn't until I added the invariant and in/out contracts to all the
functions
asserting about null that the problem's true cause became apparent.
Couldn't this happen to you with any datum that has an
bearophile wrote:
Suppose, for example, you are appending the numbers 1..5 to the array, and
somehow appended a 17. Many moons later, something crashes because the 17 was
out of range.
This bug doesn't happen in Ada (and Delphi), because you define a ranged
integer type like this:
subtype
Simen kjaeraas wrote:
Bounded!(int, 1, 5)[] myArr;
myArr ~= 1; // Compile-time error: int is not implicitly castable to
Bounded!(int, 1, 5)
myArr ~= Bounded!(int, 1, 5)( 1 ); // Works perfectly
Yes, that's it.
Simen kjaeraas wrote:
I believe you managed to miss the important part, If we could disable the
default constructor.
Yes, I believe you are correct.
retard wrote:
In a functional language:
start_the_car c = case c of
Just car - start car
Nothing - error not initialized
And the null pointer exception is reinvented!
Sat, 06 Nov 2010 11:24:01 -0700, Walter Bright wrote:
retard wrote:
In a functional language:
start_the_car c = case c of
Just car - start car
Nothing - error not initialized
And the null pointer exception is reinvented!
What was the point of my post again? To be an inspiration for
On 11/6/2010 02:47, Walter Bright wrote:
Rainer Deyke wrote:
On 11/5/2010 17:41, Walter Bright wrote:
In other words, I create an array that I mean to fill in later, because
I don't have meaningful data for it in advance.
That's a faulty idiom. A data structure that exists but contains no
Walter Bright wrote:
bearophile wrote:
Suppose, for example, you are appending the numbers 1..5 to the array,
and somehow appended a 17. Many moons later, something crashes because
the 17 was out of range.
This bug doesn't happen in Ada (and Delphi), because you define a ranged
integer
Walter Bright wrote:
bearophile wrote:
Suppose, for example, you are appending the numbers 1..5 to the
array, and somehow appended a 17. Many moons later, something crashes
because the 17 was out of range.
This bug doesn't happen in Ada (and Delphi), because you define a
ranged integer type
On Sat, 6 Nov 2010 01:21:25 -0700
Jonathan M Davis jmdavisp...@gmx.com wrote:
I believe strongly that a unit test block which has a failure should end
excecution. For many such tests, continuing would be utterly pointless, since
each successive test relies on the last.
I don't understand. I
Walter:
Suppose, for example, you are appending prime numbers to the array, and
somehow appended a 25. Many moons later, something crashes because the 25 was
not prime.
There are two main ways to avoid this bug:
- Put some test in the code, such test may be an explicit test at the point
Walter:
retard wrote:
In a functional language:
start_the_car c = case c of
Just car - start car
Nothing - error not initialized
And the null pointer exception is reinvented!
That case statement (is a pattern matching) forces you to manage the null
case everywhere you use a
On Sat, 06 Nov 2010 13:37:02 +0900, Jonathan M Davis jmdavisp...@gmx.com
wrote:
I'm proposing a possible new module for phobos which would be called
std.unittests. The code and DDoc file can be found here:
http://is.gd/gLH9Q
Or you can look at the code here directly (though it has poor
Andrei Alexandrescu:
To find an array that always has initialized data, look no further than
std::vector. There is no way to grow an std::vector without filling it
with data under user's control. The only place where std::vector assumes
a default is the resize function:
void
On Sat, 06 Nov 2010 13:09:07 +0100
Lutger lutger.blijdest...@gmail.com wrote:
Vladimir Panteleev wrote:
A while ago, someone added an example with pure functions to Wikipedia's
D article:
http://en.wikipedia.org/wiki/D_(programming_language)#Functional
Someone on the talk page
bearophile wrote:
spir:
Jonathan M Davis:
I believe strongly that a unit test block which has a failure should
end excecution. For many such tests, continuing would be utterly
pointless, since each successive test relies on the last.
I don't understand. I can have one dozen test
bearophile Wrote:
Walter:
retard wrote:
In a functional language:
start_the_car c = case c of
Just car - start car
Nothing - error not initialized
And the null pointer exception is reinvented!
That case statement (is a pattern matching) forces you to manage the
Adam Burton wrote:
I wouldn't consider that as the same thing. null represents the lack of a
value where as 25 is the wrong value. Based on that argument the application
should fail immediately on accessing the item with 25 (not many moons later)
in the same manner it does nulls, but it
Jérôme M. Berger wrote:
I thought D was supposed to be a pragmatic language? All this means
is that we need a compromise between what would be ideal (being able
to represent arbitrary conditions and have them statically enforced
at compile time) and what can be realistically achieved.
spir wrote:
On Sat, 6 Nov 2010 01:21:25 -0700
Jonathan M Davis jmdavisp...@gmx.com wrote:
I believe strongly that a unit test block which has a failure should end
excecution. For many such tests, continuing would be utterly pointless,
since
each successive test relies on the last.
I
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware does this
for
you for free.
Walter, I know you're a Windows programmer but this cannot be the first time
somebody has told you this - YOU CANNOT RECOVER FROM SEG FAULTS UNDER LINUX.
Access violations
FeepingCreature Wrote:
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware does
this for
you for free.
Walter, I know you're a Windows programmer but this cannot be the first time
somebody has told you this - YOU CANNOT RECOVER FROM SEG FAULTS
On 11/6/2010 2:14 PM, Walter Bright wrote:
Rainer Deyke wrote:
On 11/6/2010 02:42, Walter Bright wrote:
Adam D. Ruppe wrote:
It wasn't until I added the invariant and in/out contracts to all the
functions
asserting about null that the problem's true cause became apparent.
Couldn't this
Roman Ivanov Wrote:
On 11/6/2010 2:14 PM, Walter Bright wrote:
Rainer Deyke wrote:
On 11/6/2010 02:42, Walter Bright wrote:
Adam D. Ruppe wrote:
It wasn't until I added the invariant and in/out contracts to all the
functions
asserting about null that the problem's true cause became
Gary Whatmore:
You're missing the point. The reason for seg faults is to terminate the
application as quickly as possible. The developer then fires up the debugger
and fixes the app. Seg faults should never happen in production code. You
only release when all seg faults are fixed. The
Walter Bright Wrote:
Adam Burton wrote:
I wouldn't consider that as the same thing. null represents the lack of a
value where as 25 is the wrong value. Based on that argument the
application
should fail immediately on accessing the item with 25 (not many moons
later)
in the same
bearophile Wrote:
Gary Whatmore:
You're missing the point. The reason for seg faults is to terminate the
application as quickly as possible. The developer then fires up the
debugger and fixes the app. Seg faults should never happen in production
code. You only release when all seg
Walter Bright wrote:
Adam Burton wrote:
I wouldn't consider that as the same thing. null represents the lack of a
value where as 25 is the wrong value. Based on that argument the
application should fail immediately on accessing the item with 25 (not
many moons later) in the same manner it
FeepingCreature wrote:
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware does
this for you for free.
Walter, I know you're a Windows programmer but this cannot be the first time
somebody has told you this - YOU CANNOT RECOVER FROM SEG FAULTS UNDER LINUX.
Gary Whatmore:
I'm seeing it. The other arguments for non-null types also fall short because
non-nulls don't solve basic problems like arrays, basic collections in the
library (custom fill policy).
Arrays and collections are a subset of the nonull problem I am discussing
about. I have
Gary Whatmore:
Doesn't it mean that instead of complicating the language we write more unit
tests?
This is true, it's a design decision. And we are indeed trying to decide if
this feature is worth it.
A sufficiently large amount of unittests is indeed able to remove and avoid a
large
New and much more flexible static type systems are possible, like the SPARK
and ATS ones, but they require a kind of programming that asks lot of brain
from the programmer, so they are mostly for special purposes only.
Sorry, unfinished post. I was saying:
Languages like Spec#, Haskell and
Adam Burton wrote:
I *think* I undertand what you mean, however I also think I failed to
explain myself correctly. After reading bearophiles post I think he put it
in much better terms of null being a common case that is handled in common
way.
I don't see that non-null is such a special case
Sat, 06 Nov 2010 21:52:22 +0100, Jérôme M. Berger wrote:
FeepingCreature wrote:
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware
does this for you for free.
Walter, I know you're a Windows programmer but this cannot be the first
time somebody has
bearophile wrote:
Gary Whatmore:
You're missing the point. The reason for seg faults is to terminate the
application as quickly as possible. The developer then fires up the
debugger and fixes the app. Seg faults should never happen in production
code. You only release when all seg faults are
Jonathan M Davis napisał:
I'm proposing a possible new module for phobos which would be called
std.unittests. The code and DDoc file can be found here:
http://is.gd/gLH9Q
Or you can look at the code here directly (though it has poor
highlighting): http://ideone.com/EOlod
The module
Walter:
I don't see that non-null is such a special case that it would benefit from a
special case syntax.
Well, nonnull are a special cases because:
- There is a good enough way to solve this problem. This is not true in the
general case.
- null exceptions are very common bugs, among the
bearophile Wrote:
Walter:
I don't see that non-null is such a special case that it would benefit from
a
special case syntax.
Well, nonnull are a special cases because:
- There is a good enough way to solve this problem. This is not true in the
general case.
- null exceptions are
Walter:
Granted, even 100% coverage is no guarantee of no seg faults, but in practice
it
is very effective.
Unittests are widely used in Java, still null exceptions are not uncommon in
Java.
And finally, null exceptions are not a bug. They are the messenger that there
is
a bug in
Walter Bright wrote:
Adam Burton wrote:
I *think* I undertand what you mean, however I also think I failed to
explain myself correctly. After reading bearophiles post I think he put
it in much better terms of null being a common case that is handled in
common way.
I don't see that
Walter Bright Wrote:
FeepingCreature wrote:
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware does
this for you for free.
Walter, I know you're a Windows programmer but this cannot be the first time
somebody has told you this - YOU CANNOT
steveh:
citation needed. I've made software with 100% line and path coverage. No
segfaults happened ever. Spent enormous time optimizing the code and its
quality. In quality applications NPE/segfaults simply don't exist.
You are right, some citation is needed. I have seen or read many
FeepingCreature wrote:
Walter Bright Wrote:
FeepingCreature wrote:
Walter Bright Wrote:
All that does is reinvent the null pointer seg fault. The hardware does
this for you for free.
Walter, I know you're a Windows programmer but this cannot be the first
time somebody has told you this -
On Saturday 06 November 2010 12:28:02 Masahiro Nakagawa wrote:
I don't know this module's usability, but is getExcMsg useful?
I can't imagine useful situation.
In addition, I grepped your datetime.d and getExcMsg not found :(
If possible, I want the mock, stub and related features.
It's
On Saturday 06 November 2010 13:05:13 Jérôme M. Berger wrote:
spir wrote:
On Sat, 6 Nov 2010 01:21:25 -0700
Jonathan M Davis jmdavisp...@gmx.com wrote:
I believe strongly that a unit test block which has a failure should end
excecution. For many such tests, continuing would be utterly
hello,
I have a question (i would like understand), they are many important people of
D community who do not want go to D2, why ?
thanks for answer
On 11/6/2010 15:00, Walter Bright wrote:
I don't see that non-null is such a special case that it would benefit
from a special case syntax.
I'm less concerned about syntax and more about semantics. I already use
nn_ptrT (short for non-null pointer) in C++. It works in C++ because
types in C++
Michel Fortin wrote:
I'm know I should release things early to let those interested test it
and give me some feedback (and create bindings), but I'm not sure
whether it should be merged into the trunk so early. With Walter's
permission, I could publish my git repository to let people peek at
bioinfornatics:
hello,
I have a question (i would like understand), they are many important people
of D community who do not want go to D2, why ?
There aren't good D2 compilers yet beside DMD, so they use what they can. And
D1 and D2 aren't equal, D1 is simpler (and quite less fussy
1 - 100 of 140 matches
Mail list logo
