"bearophile" wrote in message
news:iihr42$rqp$1...@digitalmars.com...
>
> The replacement for assert(0) is meant to be more clear in its purpose
> compared to assert(0). It may be named thisCantHappen(), or assertZero(),
> etc.
>
I vote for "fubar();" :)
...or "fellOffTheEdgeOfTheWorld();"
.
bearophile:
> The semantics a not D-expert expects from assert(something) is to
> test that something is "true". For a class reference this means the
> pointer is not null.
This is the core of our disagreement: I think an object is not
"true" if it's invariant fails. It means the object is complet
Adam D. Ruppe:
> LOL!
I like a bit of humour to keep myself serious/sane despite the strange
discussions we have around here now and then :-)
> But, assert(0) does exactly what it says - assert this situation
> is invariably invalid.
>
> > Something like class_instance.invariant() is better b
On Saturday 05 February 2011 02:43:56 spir wrote:
> On 02/05/2011 08:29 AM, Jonathan M Davis wrote:
> > On Friday 04 February 2011 13:29:38 bearophile wrote:
> >> Jonathan M Davis:
> >>> assert(0) has the advantage of being a normal assertion in non-release
> >>> mode.
> >>
> >> What is this usefu
On 02/05/2011 08:29 AM, Jonathan M Davis wrote:
On Friday 04 February 2011 13:29:38 bearophile wrote:
Jonathan M Davis:
assert(0) has the advantage of being a normal assertion in non-release
mode.
What is this useful for? To me this looks like a significant disadvantage.
If I want a HALT (to
On Friday 04 February 2011 13:29:38 bearophile wrote:
> Jonathan M Davis:
> > assert(0) has the advantage of being a normal assertion in non-release
> > mode.
>
> What is this useful for? To me this looks like a significant disadvantage.
> If I want a HALT (to tell the compiler a point can't be re
bearophile wrote:
> What is [normal assert exceptions] useful for?
Getting a more helpful error message and stack trace.
> If I want a HALT (to tell the compiler a point can't be reached,
> etc) I want it in every kind of compilation of the program.
assert(0) does just that. Either way, the prog
On 02/04/2011 10:29 PM, bearophile wrote:
Jonathan M Davis:
assert(0) has the advantage of being a normal assertion in non-release mode.
What is this useful for? To me this looks like a significant disadvantage. If I
want a HALT (to tell the compiler a point can't be reached, etc) I want it
Jonathan M Davis:
> assert(0) has the advantage of being a normal assertion in non-release mode.
What is this useful for? To me this looks like a significant disadvantage. If I
want a HALT (to tell the compiler a point can't be reached, etc) I want it in
every kind of compilation of the program
bearophile wrote:
> - assert(0); to mean HALT, that gives some problems
I like it. It's convenient and clear - assert(0) means
you cannot proceed in any situation, and that should include
release modes. (Indeed, IMO any assert that can be proven
to fail at compile time should always remain and one
On Friday 04 February 2011 04:40:35 bearophile wrote:
> > So moving them into explicit little features makes the language more
>
> The two little features I am talking about are:
> - a halt() somewhere like in core.bitop or std.intrinsic or the default
> object module to replace assert(0); - And t
Am 04.02.2011 15:57, schrieb spir:
On 02/04/2011 01:40 PM, bearophile wrote:
So moving them into explicit little features makes the language more
The two little features I am talking about are:
- a halt() somewhere like in core.bitop or std.intrinsic or the
default object module to replace ass
On 02/04/2011 01:40 PM, bearophile wrote:
So moving them into explicit little features makes the language more
The two little features I am talking about are:
- a halt() somewhere like in core.bitop or std.intrinsic or the default object
module to replace assert(0);
What about exit()? What w
On 02/04/2011 01:16 PM, bearophile wrote:
Removing the two purposes (moving them to specialized and explicit features,
specialized little tools)
I want to stress the fact that moving those two unrelated sub-features away
from assert into specialized features is not going to increase the langu
On Friday 04 February 2011 04:30:42 bearophile wrote:
> Jonathan M Davis:
> > However, I don't see why there would be any problem with
> > assert(0) meaning halt. It's a normal assert in non-release mode and it
> > sticks around in release mode, becoming a halt instruction. I use it
> > that way al
> So moving them into explicit little features makes the language more
The two little features I am talking about are:
- a halt() somewhere like in core.bitop or std.intrinsic or the default object
module to replace assert(0);
- And to use class_instance.invariant() to replace assert(class_instan
Jonathan M Davis:
> However, I don't see why there would be any problem with
> assert(0) meaning halt. It's a normal assert in non-release mode and it
> sticks
> around in release mode, becoming a halt instruction. I use it that way all
> the
> time. I don't see any problem with it whatsoever
On Friday 04 February 2011 04:10:37 bearophile wrote:
> Andrei:
> > We need to have at least a definite decision by Feb 7 from Don and
> > Walter that work will be put or not into improving assert as discussed.
>
> I think that fixing assert() is a better strategy, even it may require more
> work.
> Removing the two purposes (moving them to specialized and explicit features,
> specialized little tools)
I want to stress the fact that moving those two unrelated sub-features away
from assert into specialized features is not going to increase the language
complexity, because those features a
Andrei:
> We need to have at least a definite decision by Feb 7 from Don and
> Walter that work will be put or not into improving assert as discussed.
I think that fixing assert() is a better strategy, even it may require more
work. A problem with assert is that it wants to do too many things,
On 2/4/11 3:27 AM, Brad Roberts wrote:
On 2/1/2011 9:12 AM, Andrei Alexandrescu wrote:
On 2/1/11 10:51 AM, Michel Fortin wrote:
On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
said:
TypeInfo holds a pointer to the toString function, so if the compiler
passes the two operands as D-style vari
On 2/1/2011 9:12 AM, Andrei Alexandrescu wrote:
> On 2/1/11 10:51 AM, Michel Fortin wrote:
>> On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
>> said:
>> TypeInfo holds a pointer to the toString function, so if the compiler
>> passes the two operands as D-style variadic arguments to the assert
>
On Tuesday 01 February 2011 11:32:08 Andrei Alexandrescu wrote:
> On 2/1/11 11:29 AM, Jonathan M Davis wrote:
> > On Tuesday 01 February 2011 09:12:16 Andrei Alexandrescu wrote:
> >> On 2/1/11 10:51 AM, Michel Fortin wrote:
> >>> On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
> >>> said:
> >>>
On 2/1/11 11:29 AM, Jonathan M Davis wrote:
On Tuesday 01 February 2011 09:12:16 Andrei Alexandrescu wrote:
On 2/1/11 10:51 AM, Michel Fortin wrote:
On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
said:
TypeInfo holds a pointer to the toString function, so if the compiler
passes the two ope
Andrei:
> Don, if you arrange things such that this user-level code:
>
> int a = 42;
> double b = 3.14;
> assert(a <= b, "Something odd happened");
>
> ultimately calls this runtime function:
>
> assertCmpFailed("<=", "42", "3.14", "Something odd happened");
>
> I promise I'll discuss with Sea
On Tuesday 01 February 2011 09:12:16 Andrei Alexandrescu wrote:
> On 2/1/11 10:51 AM, Michel Fortin wrote:
> > On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
> > said:
> > TypeInfo holds a pointer to the toString function, so if the compiler
> > passes the two operands as D-style variadic argum
On 2/1/11 10:51 AM, Michel Fortin wrote:
On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
said:
TypeInfo holds a pointer to the toString function, so if the compiler
passes the two operands as D-style variadic arguments to the assert
handler, the assert handler can use toString to print them. T
On Tuesday 01 February 2011 09:05:18 Jens Mueller wrote:
> Michel Fortin wrote:
> > On 2011-02-01 10:34:26 -0500, Andrei Alexandrescu
> >
> > said:
> > >On 2/1/11 9:21 AM, Don wrote:
> > >>Jonathan M Davis wrote:
> > >>>Do you really find
> > >>>
> > >>>assertPred!"=="(min(5, 7), 5);
> > >>>
> >
Michel Fortin wrote:
> On 2011-02-01 10:34:26 -0500, Andrei Alexandrescu
> said:
>
> >On 2/1/11 9:21 AM, Don wrote:
> >>Jonathan M Davis wrote:
> >>>Do you really find
> >>>
> >>>assertPred!"=="(min(5, 7), 5);
> >>>
> >>>to be all that harder to understand than
> >>>
> >>>assert(min(5, 7) == 5);
On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
said:
On 2/1/11 9:21 AM, Don wrote:
Jonathan M Davis wrote:
On Sunday 30 January 2011 05:28:36 SHOO wrote:
To be frank, I don't think that such a helper is necessary.
I think these helpers will harm intuitive readability of unittest code.
On 2/1/11 9:21 AM, Don wrote:
Jonathan M Davis wrote:
On Sunday 30 January 2011 05:28:36 SHOO wrote:
To be frank, I don't think that such a helper is necessary.
I think these helpers will harm intuitive readability of unittest code.
For unittest code, it is necessary to be able to understand
On 2/1/11 9:21 AM, Don wrote:
Including stuff like this could give D a reputation for lack of
readability. My belief is that right now, the #1 risk for Phobos is that
it becomes too clever and inaccessible.
I think this is also an argument in favor of making containers straight
classes.
Andr
On 2011-02-01 10:34:26 -0500, Andrei Alexandrescu
said:
On 2/1/11 9:21 AM, Don wrote:
Jonathan M Davis wrote:
Do you really find
assertPred!"=="(min(5, 7), 5);
to be all that harder to understand than
assert(min(5, 7) == 5);
I do. *Much* harder. Factor of two, at least.
In absolute term
On Tuesday 01 February 2011 07:21:54 Don wrote:
> Jonathan M Davis wrote:
> > On Sunday 30 January 2011 05:28:36 SHOO wrote:
> >> To be frank, I don't think that such a helper is necessary.
> >> I think these helpers will harm intuitive readability of unittest code.
> >> For unittest code, it is ne
On 2/1/11 9:21 AM, Don wrote:
Jonathan M Davis wrote:
On Sunday 30 January 2011 05:28:36 SHOO wrote:
To be frank, I don't think that such a helper is necessary.
I think these helpers will harm intuitive readability of unittest code.
For unittest code, it is necessary to be able to understand
Jonathan M Davis wrote:
On Sunday 30 January 2011 05:28:36 SHOO wrote:
To be frank, I don't think that such a helper is necessary.
I think these helpers will harm intuitive readability of unittest code.
For unittest code, it is necessary to be able to understand easily even
if without the docu
On Tuesday 01 February 2011 06:44:56 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Monday 31 January 2011 15:49:11 Jens Mueller wrote:
> > > spir wrote:
> > > > On 01/30/2011 01:13 PM, Jens Mueller wrote:
> > > > >I do not like putting it in std.exception. Maybe the name
> > > > >std.unittes
Jonathan M Davis wrote:
> On Monday 31 January 2011 15:49:11 Jens Mueller wrote:
> > spir wrote:
> > > On 01/30/2011 01:13 PM, Jens Mueller wrote:
> > > >I do not like putting it in std.exception. Maybe the name std.unittest
> > > >is also not good. I would propose std.assert if assert wasn't a key
On Monday 31 January 2011 15:49:11 Jens Mueller wrote:
> spir wrote:
> > On 01/30/2011 01:13 PM, Jens Mueller wrote:
> > >I do not like putting it in std.exception. Maybe the name std.unittest
> > >is also not good. I would propose std.assert if assert wasn't a keyword.
> > >[...]
> > >
> > I woul
On 02/01/2011 12:49 AM, Jens Mueller wrote:
spir wrote:
On 01/30/2011 01:13 PM, Jens Mueller wrote:
I do not like putting it in std.exception. Maybe the name std.unittest
is also not good. I would propose std.assert if assert wasn't a keyword.
[...]
I would_not_ expect helpers for writing
Jonathan M Davis wrote:
> In case you didn't know, I have a set of unit test helper functions which
> have
> been being reviewed for possible inclusion in phobos. Here's an update.
>
> Most recent code: http://is.gd/F1OHat
>
> Okay. I took the previous suggestions into consideration and adjuste
spir wrote:
> On 01/30/2011 01:13 PM, Jens Mueller wrote:
> >I do not like putting it in std.exception. Maybe the name std.unittest
> >is also not good. I would propose std.assert if assert wasn't a keyword.
> >[...]
> I would_not_ expect helpers for writing
> >assertions (Assert_Error_) in a mod
On 01/30/2011 02:13 PM, Jens Mueller wrote:
The only argument against putting in its own module is it's size. That
seems to be your main point. I think putting something in new module
should mainly be concerned with separating stuff logically. Later on it
should be easy to add a new module that i
On 01/30/2011 01:13 PM, Jens Mueller wrote:
I do not like putting it in std.exception. Maybe the name std.unittest
is also not good. I would propose std.assert if assert wasn't a keyword.
[...]
I would_not_ expect helpers for writing
assertions (Assert_Error_) in a module named std.exception.
Andrei Alexandrescu wrote:
> On 01/30/2011 06:13 AM, Jens Mueller wrote:
> >Masahiro Nakagawa wrote:
> >>
> >>I vote Andrei's suggestion, std.exception is better than new std.unittests.
> >>I think testing module should provide more features(e.g. Mock, Stub...).
> >>Your helpers help assert writing
On 01/30/2011 06:13 AM, Jens Mueller wrote:
Masahiro Nakagawa wrote:
I vote Andrei's suggestion, std.exception is better than new std.unittests.
I think testing module should provide more features(e.g. Mock, Stub...).
Your helpers help assert writing style but not help testing.
In addition, std
On Sunday 30 January 2011 06:10:25 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Sunday 30 January 2011 05:13:19 Jens Mueller wrote:
> > > My preference for distinct modules follows that line of separating
> > > errors and exceptions.
> > > The only argument against putting in its own module
Jonathan M Davis wrote:
> On Sunday 30 January 2011 05:13:19 Jens Mueller wrote:
> >
> > My preference for distinct modules follows that line of separating
> > errors and exceptions.
> > The only argument against putting in its own module is it's size. That
> > seems to be your main point. I think
On Sunday 30 January 2011 05:28:36 SHOO wrote:
> (2011/01/24 23:34), Jonathan M Davis wrote:
> > In case you didn't know, I have a set of unit test helper functions which
> > have been being reviewed for possible inclusion in phobos. Here's an
> > update.
> >
> > Most recent code: http://is.gd/F1O
On Sunday 30 January 2011 05:13:19 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Sunday 30 January 2011 04:13:59 Jens Mueller wrote:
> > > I do not like putting it in std.exception. Maybe the name std.unittest
> > > is also not good. I would propose std.assert if assert wasn't a
> > > keywor
(2011/01/24 23:34), Jonathan M Davis wrote:
In case you didn't know, I have a set of unit test helper functions which have
been being reviewed for possible inclusion in phobos. Here's an update.
Most recent code: http://is.gd/F1OHat
Okay. I took the previous suggestions into consideration and a
Jonathan M Davis wrote:
> On Sunday 30 January 2011 04:13:59 Jens Mueller wrote:
> > I do not like putting it in std.exception. Maybe the name std.unittest
> > is also not good. I would propose std.assert if assert wasn't a keyword.
> > When I use std.exception I want to handle situations that are
On Sunday 30 January 2011 04:13:59 Jens Mueller wrote:
> Masahiro Nakagawa wrote:
> > I vote Andrei's suggestion, std.exception is better than new
> > std.unittests. I think testing module should provide more features(e.g.
> > Mock, Stub...). Your helpers help assert writing style but not help
> >
Masahiro Nakagawa wrote:
>
> I vote Andrei's suggestion, std.exception is better than new std.unittests.
> I think testing module should provide more features(e.g. Mock, Stub...).
> Your helpers help assert writing style but not help testing.
> In addition, std.exception already defined similar fu
On Mon, 24 Jan 2011 23:34:49 +0900, Jonathan M Davis
wrote:
In case you didn't know, I have a set of unit test helper functions
which have
been being reviewed for possible inclusion in phobos. Here's an update.
Most recent code: http://is.gd/F1OHat
Okay. I took the previous suggestions in
On Mon, 24 Jan 2011 17:32:12 -0500, Andrew Wiley
wrote:
Here's another approach:
When you think about it, what we're after is tagging unit tests as code
examples, so why not do exactly that with annotations?
@example(Foo.bar)
unittest {
//...
}
It means there are no new keywords to worry abo
Dnia 2011-01-24, o godz. 06:34:49
Jonathan M Davis napisał(a):
> In case you didn't know, I have a set of unit test helper functions which
> have
> been being reviewed for possible inclusion in phobos. Here's an update.
>
> Most recent code: http://is.gd/F1OHat
>
> Okay. I took the previous s
On 01/24/2011 10:03 PM, Andrei Alexandrescu wrote:
One other thing, using writefln is considered bad form in unit tests
(you want *no* output if the unit test works). But many examples might
want to demonstrate how e.g. an object interacts with writefln. Any
suggestions? The assert line above is
On Mon, Jan 24, 2011 at 3:43 PM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> On 1/24/11 3:36 PM, Steven Schveighoffer wrote:
>
>> On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
>> wrote:
>>
>>> I find documented unittests attractive mainly because they're
>>> _simple_.
Steven Schveighoffer napisał:
>> BTW I consider this a very important topic. We have _plenty_ of
>> examples that don't work and are not mechanically verifiable. The
>> reasons range from minor typos to language changes to implementation
>> limitations. Generally this is what they call "documentat
On Monday, January 24, 2011 13:35:22 Andrei Alexandrescu wrote:
> On 1/24/11 3:16 PM, Nick Sabalausky wrote:
> > "Andrej Mitrovic" wrote in message
> > news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
> >
> >> It's often the case that you want documentation examples to be short,
>
On Mon, 24 Jan 2011 16:43:39 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 3:36 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
I find documented unittests attractive mainly because they're
_simple_. As soon as we start to add that kind of stuf
Andrei Alexandrescu wrote:
Documentation is a reference, not a novel. If someone looked up the
documentation for "bar", why make them jump over to "foo" (and make sure
they know to do so) to see bar's examples?
Then there better are two examples, one focused on foo and the other on
bar. Any
On Mon, 24 Jan 2011 16:36:21 -0500, Steven Schveighoffer
wrote:
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
Yah, that is an issue. For examples that do non-unittesty stuff (e.g.
writeln, use sockets etc.) we can still use the old-style documentation.
That sounds rea
On 01/25/2011 12:16 AM, Nick Sabalausky wrote:
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't
Steven Schveighoffer wrote:
If DIP9 is accepted (writeTo), then showing examples of how the format
specifiers work would certainly look less confusing via writefln.
I thought this was what std.format was for.
--
Simen
On 1/24/11 3:36 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
I find documented unittests attractive mainly because they're
_simple_. As soon as we start to add that kind of stuff... exponential
decay.
It's only not simple if you want it to be.
On Mon, 24 Jan 2011 16:07:38 -0500, Andrej Mitrovic
wrote:
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want to put in the documentation. Sounds like a perfect
candidate for named unittests
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I
On 1/24/11 3:16 PM, Nick Sabalausky wrote:
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want
On 1/24/11 3:12 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:ihkpin$194m$1...@digitalmars.com...
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
The second one could be pretty annoying. Consider cases where several
functions interact (I've seen this many times on Micr
Daniel Gibson wrote:
> Am 24.01.2011 21:39, schrieb Jens Mueller:
> >Andrei Alexandrescu wrote:
> >>On 1/24/11 1:50 PM, Jens Mueller wrote:
> >>>Jonathan M Davis wrote:
> I think that it's been discussed a time or two, but nothing has been done
> about
> it. It wouldn't be entirely str
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
> It's often the case that you want documentation examples to be short,
> but also correct. But you still want to write complex unittests that
> you don't want to put in the documentation. Sounds li
"Andrei Alexandrescu" wrote in message
news:ihkpin$194m$1...@digitalmars.com...
> On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
>> The second one could be pretty annoying. Consider cases where several
>> functions interact (I've seen this many times on Microsoft's
>> Documentation), and it make
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want to put in the documentation. Sounds like a perfect
candidate for named unittests:
unittest(ddoc)
{
// outputted in documentation
}
Here "ddo
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
On Monday 24 January 2011 12:15:07 Andrei Alexandrescu wrote:
> On 1/24/11 1:50 PM, Jens Mueller wrote:
> > Jonathan M Davis wrote:
> >> I think that it's been discussed a time or two, but nothing has been
> >> done about it. It wouldn't be entirely straightforward to do.
> >> Essentially, either a
Am 24.01.2011 21:39, schrieb Jens Mueller:
Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittes
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
done about
it. It wouldn't be entirely straight
Andrei Alexandrescu wrote:
> On 1/24/11 1:50 PM, Jens Mueller wrote:
> >Jonathan M Davis wrote:
> >>I think that it's been discussed a time or two, but nothing has been done
> >>about
> >>it. It wouldn't be entirely straightforward to do. Essentially, either a
> >>unittest block would have to be g
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittest block would have to be
"Jonathan M Davis" wrote in message
news:mailman.888.1295879701.4748.digitalmar...@puremagic.com...
> In case you didn't know, I have a set of unit test helper functions which
> have
> been being reviewed for possible inclusion in phobos. Here's an update.
>
> Most recent code: http://is.gd/F1OH
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittest block would have to be generated from the Examples section in the
docu
Jonathan M Davis wrote:
> On Monday, January 24, 2011 09:55:52 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > In case you didn't know, I have a set of unit test helper functions which
> > > have been being reviewed for possible inclusion in phobos. Here's an
> > > update.
> > >
> > > Most r
On Monday, January 24, 2011 09:55:52 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > In case you didn't know, I have a set of unit test helper functions which
> > have been being reviewed for possible inclusion in phobos. Here's an
> > update.
> >
> > Most recent code: http://is.gd/F1OHat
> >
>
Jonathan M Davis wrote:
> In case you didn't know, I have a set of unit test helper functions which
> have
> been being reviewed for possible inclusion in phobos. Here's an update.
>
> Most recent code: http://is.gd/F1OHat
>
> Okay. I took the previous suggestions into consideration and adjuste
On Monday 24 January 2011 07:48:25 Andrej Mitrovic wrote:
> Maybe if we get that "any" function any time soon (pardon the pun), we
> could simplify those constraints a little bit:
>
> enum string[] binaryOps = ["+", "-", "*", "/", "%", "^^", "&", "|",
> "^", "<<", ">>", ">>>", "~"];
>
> void asse
Maybe if we get that "any" function any time soon (pardon the pun), we
could simplify those constraints a little bit:
enum string[] binaryOps = ["+", "-", "*", "/", "%", "^^", "&", "|",
"^", "<<", ">>", ">>>", "~"];
void assertPred(string op, L, R, E)
(L lhs, R rhs, E expected, laz
On Monday 24 January 2011 06:34:49 Jonathan M Davis wrote:
> In case you didn't know, I have a set of unit test helper functions which
> have been being reviewed for possible inclusion in phobos. Here's an
> update.
>
> Most recent code: http://is.gd/F1OHat
>
> Okay. I took the previous suggestio
In case you didn't know, I have a set of unit test helper functions which have
been being reviewed for possible inclusion in phobos. Here's an update.
Most recent code: http://is.gd/F1OHat
Okay. I took the previous suggestions into consideration and adjusted the code
a
bit more. However, most
90 matches
Mail list logo
