On 5/1/14, 9:07 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 15:37:21 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 8:04 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 14:55:50 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 1:34 AM, Dicebot wrote:
I have just recently went through some of out
Le 01/05/2014 13:44, w0rp a écrit :
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all unittests. --
Andrei
I recommend running the tests in random order as well.
This is a
Le 01/05/2014 16:01, Atila Neves a écrit :
On Thursday, 1 May 2014 at 11:44:12 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing all unittests. --
Andrei
I
On Thu, 01 May 2014 12:07:19 -0400, Dicebot pub...@dicebot.lv wrote:
On Thursday, 1 May 2014 at 15:37:21 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 8:04 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 14:55:50 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 1:34 AM, Dicebot wrote:
I have just
On Thu, 01 May 2014 10:01:19 -0400, Atila Neves atila.ne...@gmail.com
wrote:
On Thursday, 1 May 2014 at 11:44:12 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we should look into parallelizing
On 5/1/14, 10:09 AM, Steven Schveighoffer wrote:
On Thu, 01 May 2014 12:07:19 -0400, Dicebot pub...@dicebot.lv wrote:
On Thursday, 1 May 2014 at 15:37:21 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 8:04 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 14:55:50 UTC, Andrei Alexandrescu wrote:
On
On Thursday, 1 May 2014 at 17:24:58 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 10:09 AM, Steven Schveighoffer wrote:
On Thu, 01 May 2014 12:07:19 -0400, Dicebot
pub...@dicebot.lv wrote:
On Thursday, 1 May 2014 at 15:37:21 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 8:04 AM, Dicebot wrote:
On
On 5/1/14, 10:32 AM, Brad Anderson wrote:
It hasn't been C:\TEMP for almost 13 years
About the time when I switched :o). -- Andrei
On Wednesday, 30 April 2014 at 16:19:48 UTC, Byron wrote:
On Wed, 30 Apr 2014 09:02:54 -0700, Andrei Alexandrescu wrote:
I think indeed a small number of unittests rely on order of
execution.
Maybe nested unittests?
unittest OrderTests {
// setup for all child tests?
unittest a {
}
On Thu, 01 May 2014 13:25:00 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/1/14, 10:09 AM, Steven Schveighoffer wrote:
On Thu, 01 May 2014 12:07:19 -0400, Dicebot pub...@dicebot.lv wrote:
On Thursday, 1 May 2014 at 15:37:21 UTC, Andrei Alexandrescu wrote:
On 5/1/14,
On 5/1/14, 10:41 AM, Jason Spencer wrote:
On Wednesday, 30 April 2014 at 16:19:48 UTC, Byron wrote:
On Wed, 30 Apr 2014 09:02:54 -0700, Andrei Alexandrescu wrote:
I think indeed a small number of unittests rely on order of execution.
Maybe nested unittests?
unittest OrderTests {
//
On Thursday, 1 May 2014 at 17:04:53 UTC, Xavier Bigand wrote:
Le 01/05/2014 16:01, Atila Neves a écrit :
On Thursday, 1 May 2014 at 11:44:12 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg wrote:
On 2014-04-30 23:35, Andrei Alexandrescu wrote:
Agreed. I think we
On 2014-05-01 19:12, Steven Schveighoffer wrote:
But not a great way to debug it.
If your test failure depends on ordering, then the next run will be
random too.
Proposal runtime parameter for pre-main consumption:
./myprog --rndunit[=seed]
To run unit tests randomly. Prints out as first
On Thu, 01 May 2014 10:42:54 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Thu, 01 May 2014 00:49:53 -0400, Jonathan M Davis via
Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wed, 30 Apr 2014 20:33:06 -0400
Steven Schveighoffer via Digitalmars-d
On 2014-05-01 17:15, Andrei Alexandrescu wrote:
That's all nice, but I feel we're going gung ho with overengineering
already. If we give unittests names and then offer people a button
parallelize unittests to push (don't even specify the number of
threads! let the system figure it out depending
Am Thu, 01 May 2014 08:07:51 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/1/14, 4:31 AM, Johannes Pfau wrote:
@Andrei do you think having to explicitly import modules to be
tested is an issue?
Well it kinda is. All that's written on the package is unittest, we
On 5/1/14, 11:49 AM, Jacob Carlborg wrote:
On 2014-05-01 17:15, Andrei Alexandrescu wrote:
That's all nice, but I feel we're going gung ho with overengineering
already. If we give unittests names and then offer people a button
parallelize unittests to push (don't even specify the number of
On 5/1/14, 12:05 PM, Johannes Pfau wrote:
Am Thu, 01 May 2014 08:07:51 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/1/14, 4:31 AM, Johannes Pfau wrote:
@Andrei do you think having to explicitly import modules to be
tested is an issue?
Well it kinda is. All that's
Last but not least, virtually nobody I know runs unittests and then
main. This is quickly becoming an idiom:
version(unittest) void main() {}
else void main()
{
...
}
I think it's time to change that.
The current system of running unit tests prior to main is, in my opinion,
Am Thu, 01 May 2014 12:26:07 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/1/14, 12:05 PM, Johannes Pfau wrote:
Here's the revived pull request:
https://github.com/D-Programming-Language/dmd/pull/3518
https://github.com/D-Programming-Language/druntime/pull/782
On 5/1/14, 12:47 PM, Johannes Pfau wrote:
Am Thu, 01 May 2014 12:26:07 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/1/14, 12:05 PM, Johannes Pfau wrote:
Here's the revived pull request:
https://github.com/D-Programming-Language/dmd/pull/3518
Am Thu, 01 May 2014 13:00:44 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
Nothing. This just changes the way druntime internally handles the
unit tests, but nothing changes for the user:
Great, thanks. Just making sure there's no unstated assumptions
somewhere. Help
On Thursday, 1 May 2014 at 17:57:05 UTC, Andrei Alexandrescu
wrote:
Well how complicated can we make it all? -- Andrei
As simple as possible, but no simpler :)
I've seen you favor this or that feature because it would make
unit testing easier and more accessible, and eschew features that
On 5/1/14, 2:28 PM, Jason Spencer wrote:
On Thursday, 1 May 2014 at 17:57:05 UTC, Andrei Alexandrescu wrote:
Well how complicated can we make it all? -- Andrei
As simple as possible, but no simpler :)
I've seen you favor this or that feature because it would make unit
testing easier and more
On 5/1/14, 4:22 PM, Andrei Alexandrescu wrote:
On 5/1/14, 11:49 AM, Jacob Carlborg wrote:
On 2014-05-01 17:15, Andrei Alexandrescu wrote:
That's all nice, but I feel we're going gung ho with overengineering
already. If we give unittests names and then offer people a button
parallelize
On Thu, 01 May 2014 14:40:41 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 5/1/14, 2:28 PM, Jason Spencer wrote:
But it seems the key question is whether order can EVER be
important for any reason. I for one would be willing to give up
parallelization to
On Thursday, 1 May 2014 at 21:40:38 UTC, Andrei Alexandrescu
wrote:
I'll be blunt. What you say is technically sound (which is
probably why you believe it is notable)...
Well, I suppose that's not the MOST insulting brush-off I could
hope for, but it falls short of encouraging me to
On Friday, 2 May 2014 at 03:04:39 UTC, Jason Spencer wrote:
If we don't want to consider how we can accommodate both camps
here, then I must at least support Jonathan's modest suggestion
that parallel UTs require active engagement rather than being
the default.
Use chroot() and fork().
On 5/1/2014 12:32 AM, bearophile wrote:
This is just the basic idea, and perhaps people suggested something better than
this.
You've already got it working with version, that's what version is for. Why add
yet another way to do it?
Hello,
A coworker mentioned the idea that unittests could be run in parallel
(using e.g. a thread pool). I've rigged things to run in parallel
unittests across modules, and that works well. However, this is too
coarse-grained - it would be great if each unittest could be pooled
across the
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in
parallel
In D we have strong purity to make more safe to run code in
parallel:
pure unittest {}
We've resisted named unittests but I think there's enough
evidence to make the change.
Yes, the optional
Am Wed, 30 Apr 2014 08:43:31 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
However, this is too
coarse-grained - it would be great if each unittest could be pooled
across the thread pool. That's more difficult to implement.
I filed a pull request which allowed running
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in parallel
In D we have strong purity to make more safe to run code in parallel:
pure unittest {}
This doesn't follow. All unittests should be executable concurrently. --
On 4/30/14, 8:54 AM, Johannes Pfau wrote:
Am Wed, 30 Apr 2014 08:43:31 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
However, this is too
coarse-grained - it would be great if each unittest could be pooled
across the thread pool. That's more difficult to implement.
I filed
On Wed, 30 Apr 2014 09:02:54 -0700, Andrei Alexandrescu wrote:
I think indeed a small number of unittests rely on order of execution.
Those will be still runnable with a fork factor of 1. We'd need a way to
specify that - either a flag or:
static shared this() { Runtime.unittestThreads =
On Wednesday, 30 April 2014 at 15:43:35 UTC, Andrei Alexandrescu
wrote:
Hello,
A coworker mentioned the idea that unittests could be run in
parallel (using e.g. a thread pool). I've rigged things to run
in parallel unittests across modules, and that works well.
However, this is too
On 4/30/14, 9:19 AM, Byron wrote:
On Wed, 30 Apr 2014 09:02:54 -0700, Andrei Alexandrescu wrote:
I think indeed a small number of unittests rely on order of execution.
Those will be still runnable with a fork factor of 1. We'd need a way to
specify that - either a flag or:
static shared
On 4/30/14, 9:24 AM, QAston wrote:
An existing library implementation:
https://github.com/atilaneves/unit-threaded
Nice! The Warning: With dmd 2.064.2 and the gold linker on Linux 64-bit
this code crashes. is hardly motivating though :o).
I think this project is a confluence of a couple
Am Wed, 30 Apr 2014 09:28:18 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
I also wonder if its just better to extend/expose the unittest API
for more advanced things like order of execution, test reporting,
and parallel execution. And we can just support an external
Am Wed, 30 Apr 2014 09:02:54 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
https://github.com/D-Programming-Language/dmd/pull/1131
https://github.com/D-Programming-Language/druntime/pull/308
To summarize: It provides a function pointer for every unit test to
druntime
On Wed, Apr 30, 2014 at 08:43:31AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
Last but not least, virtually nobody I know runs unittests and then
main. This is quickly becoming an idiom:
version(unittest) void main() {}
else void main()
{
...
}
I think it's time to
On Wednesday, 30 April 2014 at 16:24:16 UTC, QAston wrote:
On Wednesday, 30 April 2014 at 15:43:35 UTC, Andrei
Alexandrescu wrote:
Hello,
A coworker mentioned the idea that unittests could be run in
parallel (using e.g. a thread pool). I've rigged things to run
in parallel unittests across
As a note, I'm one of those that have used the main function in
addition to unittests. I use it in the unittest build mode of my JSON
serialization library, using the unittests to ensure I didn't break
anything, and then using the main to run a performance test that my
changes actually did make it
On Wednesday, 30 April 2014 at 16:32:19 UTC, Andrei Alexandrescu
wrote:
On 4/30/14, 9:24 AM, QAston wrote:
An existing library implementation:
https://github.com/atilaneves/unit-threaded
Nice! The Warning: With dmd 2.064.2 and the gold linker on
Linux 64-bit this code crashes. is hardly
I believe only missing step right now is propagation of UDA's to
RTInfo when demanded. Everything else can be done as Phobos
solution.
And if requirement to have all modules transitively accessible
from root one is acceptable it can be already done with
On Wed, 30 Apr 2014 08:59:42 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in
parallel
In D we have strong purity to make more safe
On Wednesday, 30 April 2014 at 17:50:34 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 08:59:42 -0700
Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker mentioned the idea that
On Wednesday, 30 April 2014 at 17:30:30 UTC, Dicebot wrote:
I believe only missing step right now is propagation of UDA's
to RTInfo when demanded. Everything else can be done as Phobos
solution.
And if requirement to have all modules transitively accessible
from root one is acceptable it can
Andrei Alexandrescu wrote in message
news:ljr6ld$1mft$2...@digitalmars.com...
This doesn't follow. All unittests should be executable concurrently. --
Andrei
That's like saying all makefiles should work with -j
On Wed, 30 Apr 2014 17:58:34 +
Atila Neves via Digitalmars-d digitalmars-d@puremagic.com wrote:
Unit tests though, by definition (and I'm aware there are more
than one) have to be independent. Have to not touch the
filesystem, or the network. Only CPU and RAM.
I disagree with this. A
On Wednesday, 30 April 2014 at 15:54:42 UTC, bearophile wrote:
We've resisted named unittests but I think there's enough
evidence to make the change.
Yes, the optional name for unittests is an improvement:
unittest {}
unittest foo {}
I am very glad your coworker find such usability problems
On 4/30/2014 8:54 AM, bearophile wrote:
I'd also like some built-in way (or partially built-in) to use a module only as
main module (to run its demos) or as module to be imported. This problem is
solved in Python with the if __name__ == __main__: idiom.
dmd foo.d -unittest -main
monarch_dodra:
If we do name the unittests, then can we name them with
strings? No need to polute namespace with ugly symbols.
Are UDAs enough?
@uname(foo) unittest {}
What I'd like is to tie one or more unittests to other entities,
like all the unittests of a specific function.
Bye,
On Wednesday, 30 April 2014 at 18:19:34 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 17:58:34 +
Atila Neves via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Unit tests though, by definition (and I'm aware there are more
than one) have to be independent. Have to
On 4/30/14, bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
What I'd like is to tie one or more unittests to other entities,
like all the unittests of a specific function.
This would also lead to a more stable documented unittest feature and
the ability to declare documented
On Wednesday, 30 April 2014 at 18:04:43 UTC, Atila Neves wrote:
On Wednesday, 30 April 2014 at 17:30:30 UTC, Dicebot wrote:
I believe only missing step right now is propagation of UDA's
to RTInfo when demanded. Everything else can be done as Phobos
solution.
And if requirement to have all
On Wed, 2014-04-30 at 10:50 -0700, Jonathan M Davis via Digitalmars-d
wrote:
[…]
In general, I agree. In reality, there are times when having state
across unit tests makes sense - especially when there's expensive setup
required for the tests. While it's not something that I generally
like to
On Wed, 2014-04-30 at 11:19 -0700, Jonathan M Davis via Digitalmars-d
wrote:
[…]
I disagree with this. A unit test is a test that tests a single piece
of functionality - generally a function - and there are functions which
have to access the file system or network. And those tests are done in
On 2014-04-30 17:43, Andrei Alexandrescu wrote:
Hello,
A coworker mentioned the idea that unittests could be run in parallel
(using e.g. a thread pool). I've rigged things to run in parallel
unittests across modules, and that works well. However, this is too
coarse-grained - it would be great
On 2014-04-30 19:30, Dicebot wrote:
I believe only missing step right now is propagation of UDA's to RTInfo
when demanded. Everything else can be done as Phobos solution.
I don't see why this is necessary for this case.
--
/Jacob Carlborg
On 4/30/14, 10:58 AM, Atila Neves wrote:
We could always make running in threads opt-in.
Yah, great idea. -- Andrei
On 4/30/14, 10:50 AM, Jonathan M Davis via Digitalmars-d wrote:
There
is nothing whatsoever in the language which guarantees that running
them in parallel will work or even makes sense.
Default thread-local globals? -- Andrei
On 4/30/14, 11:13 AM, Daniel Murphy wrote:
Andrei Alexandrescu wrote in message
news:ljr6ld$1mft$2...@digitalmars.com...
This doesn't follow. All unittests should be executable concurrently.
-- Andrei
That's like saying all makefiles should work with -j
They should. -- Andrei
On 4/30/14, 11:53 AM, monarch_dodra wrote:
On Wednesday, 30 April 2014 at 15:54:42 UTC, bearophile wrote:
We've resisted named unittests but I think there's enough
evidence to make the change.
Yes, the optional name for unittests is an improvement:
unittest {}
unittest foo {}
I am very glad
On 4/30/14, 1:09 PM, Russel Winder via Digitalmars-d wrote:
And even then all tests can
and should be parallelized. If they cannot be then there is an
inappropriate dependency.
Agreed. -- Andrei
On 4/30/14, 1:19 PM, Jacob Carlborg wrote:
On 2014-04-30 17:43, Andrei Alexandrescu wrote:
Hello,
A coworker mentioned the idea that unittests could be run in parallel
(using e.g. a thread pool). I've rigged things to run in parallel
unittests across modules, and that works well. However,
On Wednesday, 30 April 2014 at 19:20:20 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 18:04:43 UTC, Atila Neves wrote:
On Wednesday, 30 April 2014 at 17:30:30 UTC, Dicebot wrote:
I believe only missing step right now is propagation of UDA's
to RTInfo when demanded. Everything else can be
On Wednesday, 30 April 2014 at 18:19:34 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 17:58:34 +
Atila Neves via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Unit tests though, by definition (and I'm aware there are more
than one) have to be independent. Have to
On Wed, 30 Apr 2014 13:26:40 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 4/30/14, 10:50 AM, Jonathan M Davis via Digitalmars-d wrote:
There
is nothing whatsoever in the language which guarantees that running
them in parallel will work or even makes
On Wed, 30 Apr 2014 18:53:22 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wednesday, 30 April 2014 at 15:54:42 UTC, bearophile wrote:
We've resisted named unittests but I think there's enough
evidence to make the change.
Yes, the optional name for unittests
On 4/30/14, 2:25 PM, Jonathan M Davis via Digitalmars-d wrote:
Sure, that helps, but it's trivial to write a unittest block which
depends on a previous unittest block, and as soon as a unittest block
uses an external resource such as a socket or file, then even if a
unittest block doesn't
On 4/30/14, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
This brings up the issue of naming unittests.
See also this ER where I discuss why I wanted this recently:
https://issues.dlang.org/show_bug.cgi?id=12473
On Wed, 30 Apr 2014 21:09:14 +0100
Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wed, 2014-04-30 at 11:19 -0700, Jonathan M Davis via Digitalmars-d
wrote:
unittest blocks just like any other unit test. I would very much
consider std.file's tests to be unit tests. But
On Wed, Apr 30, 2014 at 02:48:38PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
On Wed, 30 Apr 2014 21:09:14 +0100
Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote:
[...]
In which case D is wrong to allow them in the unittest blocks and
should introduce a new way of
On Wed, Apr 30, 2014 at 02:25:22PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]
Sure, that helps, but it's trivial to write a unittest block which
depends on a previous unittest block, and as soon as a unittest block
uses an external resource such as a socket or file, then even if a
What about allowing pure marking on unittests, and those
unittests that
are marked pure will be parallelized, and those that aren't
marked will
be run serially?
I guess that goes for inferred purity aswell...
On Wed, 30 Apr 2014 13:50:10 -0400, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wed, 30 Apr 2014 08:59:42 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker
On Wed, 30 Apr 2014 11:43:31 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Hello,
A coworker mentioned the idea that unittests could be run in parallel
(using e.g. a thread pool). I've rigged things to run in parallel
unittests across modules, and that works well.
Le 30/04/2014 17:43, Andrei Alexandrescu a écrit :
Hello,
A coworker mentioned the idea that unittests could be run in parallel
(using e.g. a thread pool). I've rigged things to run in parallel
unittests across modules, and that works well. However, this is too
coarse-grained - it would be
Le 30/04/2014 17:59, Andrei Alexandrescu a écrit :
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in parallel
In D we have strong purity to make more safe to run code in parallel:
pure unittest {}
This doesn't follow.
Le 30/04/2014 19:50, Jonathan M Davis via Digitalmars-d a écrit :
On Wed, 30 Apr 2014 08:59:42 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run
Le 30/04/2014 19:58, Atila Neves a écrit :
On Wednesday, 30 April 2014 at 17:50:34 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 08:59:42 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei
Le 30/04/2014 21:23, Dicebot a écrit :
On Wednesday, 30 April 2014 at 18:19:34 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 17:58:34 +
Atila Neves via Digitalmars-d digitalmars-d@puremagic.com wrote:
Unit tests though, by definition (and I'm aware there are more than
On 4/30/14, 6:20 PM, Xavier Bigand wrote:
Le 30/04/2014 17:59, Andrei Alexandrescu a écrit :
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in parallel
In D we have strong purity to make more safe to run code in
Le 30/04/2014 22:09, Russel Winder via Digitalmars-d a écrit :
On Wed, 2014-04-30 at 11:19 -0700, Jonathan M Davis via Digitalmars-d
wrote:
[…]
I disagree with this. A unit test is a test that tests a single piece
of functionality - generally a function - and there are functions which
have to
Le 30/04/2014 18:19, Byron a écrit :
On Wed, 30 Apr 2014 09:02:54 -0700, Andrei Alexandrescu wrote:
I think indeed a small number of unittests rely on order of execution.
Those will be still runnable with a fork factor of 1. We'd need a way to
specify that - either a flag or:
static shared
Le 01/05/2014 03:54, Andrei Alexandrescu a écrit :
On 4/30/14, 6:20 PM, Xavier Bigand wrote:
Le 30/04/2014 17:59, Andrei Alexandrescu a écrit :
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in parallel
In D we have
On Wed, 30 Apr 2014 15:33:17 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wed, Apr 30, 2014 at 02:48:38PM -0700, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 21:09:14 +0100
Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote:
[...]
On Wed, 30 Apr 2014 20:33:06 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Wed, 30 Apr 2014 13:50:10 -0400, Jonathan M Davis via
Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wed, 30 Apr 2014 08:59:42 -0700
Andrei Alexandrescu via Digitalmars-d
On Wed, 30 Apr 2014 14:35:45 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Agreed. I think we should look into parallelizing all unittests. --
I'm all for parallelizing all unittest blocks that are pure, as doing
so would be safe, but I think that we're making a
On Wednesday, 30 April 2014 at 15:43:35 UTC, Andrei Alexandrescu
wrote:
This brings up the issue of naming unittests. It's becoming
increasingly obvious that anonymous unittests don't quite scale
A message structured like this would be awesome.
Unittest Failed foo.d:345 Providing null
On 4/30/14, 10:01 PM, Jonathan M Davis via Digitalmars-d wrote:
I'm all for parallelizing all unittest blocks that are pure, as doing
so would be safe, but I think that we're making a big mistake if we try
and insist that all unittest blocks be able to be run in parallel. Any
that aren't pure
101 - 192 of 192 matches
Mail list logo
