running "dub test" without
changing all of the default configurations?
* Do I have to completely define all of the configurations that
dub provides by default once I decide to make a custom
configuration?
* If so, how can I see what the boilerplate would be for all of
those configu
things including removing the normal release and debug builds and
trying to build as a shared library instead of an application.
I believe I have a dub.json configuration question that boils
down to:
* How do I add a dependency when running "dub test" without
changing all of t
On Thursday, 22 March 2018 at 05:00:07 UTC, John Belmonte wrote:
On Thursday, 22 March 2018 at 04:25:00 UTC, Seb wrote:
- Every time a PR is merged at dmd, druntime or phobos ALL
auto-tester results get invalidated
If a change on the destination branch causes a PR to require an
automatic merg
On Thursday, 22 March 2018 at 04:25:00 UTC, Seb wrote:
- Every time a PR is merged at dmd, druntime or phobos ALL
auto-tester results get invalidated
If a change on the destination branch causes a PR to require an
automatic merge, certainly build and tests should be rerun. But
if the two cha
On Thursday, 22 March 2018 at 04:17:52 UTC, Mike Franklin wrote:
On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote:
I'm still rather puzzled. My pull request remains with 8
tests pending after several hours. I can't find any
confirmation on the pulls display
https://auto-teste
On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote:
On Thursday, 22 March 2018 at 01:51:49 UTC, Mike Franklin wrote:
I believe what happened is a different PR was merged. When a
PR is merged, all tests are invalidated, and the autotester
begins testing them again.
There is also
On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote:
I'm still rather puzzled. My pull request remains with 8 tests
pending after several hours. I can't find any confirmation on
the pulls display
https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 that
it intends to run th
On Thursday, 22 March 2018 at 04:17:52 UTC, Mike Franklin wrote:
Let's see what happens after the auto-tester starts testing it
again.
Note that it could be a while, as there are PRs that will be
getting merged in the next 24 hours that will restart the test
queue.
Mike
On Thursday, 22 March 2018 at 01:51:49 UTC, Mike Franklin wrote:
I believe what happened is a different PR was merged. When a
PR is merged, all tests are invalidated, and the autotester
begins testing them again.
There is also a priority affecting which PRs get tested first.
Those that are
On Thursday, 22 March 2018 at 01:46:08 UTC, John Belmonte wrote:
I'm trying to understand why my pull request was queued in D2
Auto-Test for only 2 of 8 tests, with the remaining left in
pending state.
https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1&repoid=1&am
I'm trying to understand why my pull request was queued in D2
Auto-Test for only 2 of 8 tests, with the remaining left in
pending state.
https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1&repoid=1&pullid=8051
Since there are pending tests, I'd expect i
On Tuesday, 9 January 2018 at 21:59:58 UTC, Ali Çehreli wrote:
On 01/09/2018 01:33 PM, H. S. Teoh wrote:
> On Tue, Jan 09, 2018 at 09:08:11PM +, Brian Schott via
Digitalmars-d wrote:
> This made me smile and cringe at the same time.
I took it as Brian Schott humor right away. :)
I was actu
On 01/09/2018 01:33 PM, H. S. Teoh wrote:
> On Tue, Jan 09, 2018 at 09:08:11PM +, Brian Schott via
Digitalmars-d wrote:
> [...]
>> I'm posting here so that this doesn't get lost in the bug tracker.
> [...]
>
> This made me smile and cringe at the same time.
I took it as Brian Schott humor r
On Tue, Jan 09, 2018 at 09:08:11PM +, Brian Schott via Digitalmars-d wrote:
[...]
> I'm posting here so that this doesn't get lost in the bug tracker.
[...]
This made me smile and cringe at the same time. I thought it was stuff
posted *here* on the forum that get lost and forgotten, buried un
With some of the changes that are part of release of 2.078.0,
this old bug can be more easily reproduced. I'm posting here so
that this doesn't get lost in the bug tracker.
Fortunately I can work around this by disabling optimizations on
one or two executables, but it would be nice to have thi
A test program I added to core/thread.d as a part of a pull request
fails with only the 32-bit Darwin (OSX) tests:
https://github.com/dlang/druntime/pull/1989
Here is the bug:
https://issues.dlang.org/show_bug.cgi?id=18063
I was able to reproduce the issue on a MacBook Pro. Unfortunately
On 2017-06-10 00:34, Seb wrote:
Don't worry about that. It's just a computer. As a temporary workaround,
docker might be worth considering.
Wow. Just modify the Makefile.
--
/Jacob Carlborg
On Sat, Jun 10, 2017 at 12:33:39AM +, Seb via Digitalmars-d wrote:
> On Saturday, 10 June 2017 at 00:16:13 UTC, H. S. Teoh wrote:
> > On Sat, Jun 10, 2017 at 02:27:13AM +0300, ketmar via Digitalmars-d
> > wrote:
> > > H. S. Teoh wrote:
> > >
> > > > [...]
> > >
> > > we can use UDAs to do tha
H. S. Teoh wrote:
On Sat, Jun 10, 2017 at 02:27:13AM +0300, ketmar via Digitalmars-d wrote:
H. S. Teoh wrote:
On a tangential note, now that I finally got the miserable test
suite running, I've managed to figure out that the problem in my dmd
PR was caused by src/ddmd/globals.h not
On Saturday, 10 June 2017 at 00:16:13 UTC, H. S. Teoh wrote:
On Sat, Jun 10, 2017 at 02:27:13AM +0300, ketmar via
Digitalmars-d wrote:
H. S. Teoh wrote:
> [...]
we can use UDAs to do that! just make the generator import the
relevand dmd parts, and then use compile-time introspection to
build
On Sat, Jun 10, 2017 at 02:27:13AM +0300, ketmar via Digitalmars-d wrote:
> H. S. Teoh wrote:
>
> > On a tangential note, now that I finally got the miserable test
> > suite running, I've managed to figure out that the problem in my dmd
> > PR was caused by src/
H. S. Teoh wrote:
On a tangential note, now that I finally got the miserable test suite
running, I've managed to figure out that the problem in my dmd PR was
caused by src/ddmd/globals.h not being auto-generated from
src/ddmd/globals.d, so when I added new fields to the Global struct,
On Fri, Jun 09, 2017 at 10:34:00PM +, Seb via Digitalmars-d wrote:
> On Friday, 9 June 2017 at 22:14:30 UTC, H. S. Teoh wrote:
> > I'm trying to track down an autotester failure in a DMD PR, and
> > getting very frustrated that the DMD test suite does not run on
> > D
it's even worser than that: unittests ultimatively fails with binutils 2.28
(at least on x86 without PIC), so i was forced to downgrade binutils to 2.26.
On Friday, 9 June 2017 at 22:14:30 UTC, H. S. Teoh wrote:
I'm trying to track down an autotester failure in a DMD PR, and
getting very frustrated that the DMD test suite does not run on
Debian/Linux because of the whole PIE-by-default fiasco that
necessitates compiling everything with
I'm trying to track down an autotester failure in a DMD PR, and getting
very frustrated that the DMD test suite does not run on Debian/Linux
because of the whole PIE-by-default fiasco that necessitates compiling
everything with -fPIC.
(1) Currently, there is no way to customize how test/Mak
// Round floating point numbers
import std.algorithm, std.conv, std.functional,
std.math, std.regex, std.stdio;
alias round = pipe!(to!real, std.math.round, to!string);
static reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`;
void main()
{
// Replace anything that looks like a real
// numb
While trying to make a few minor contributions during the
holidays, it seemed like every other PR was hitting a "random"
unit test failure.
So I solved the few that I noticed [1-3] (the last is still
waiting review / merge.)
However finding failures that have gone unnoticed or
On Saturday, 29 October 2016 at 11:25:17 UTC, Nicholas Wilson
wrote:
On Saturday, 29 October 2016 at 10:21:02 UTC, Guillaume Piolat
wrote:
On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson
wrote:
If you have any experience with either OpenCL or CUDA we'd
love to have your input.
On Saturday, 29 October 2016 at 10:21:02 UTC, Guillaume Piolat
wrote:
On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson
wrote:
If you have any experience with either OpenCL or CUDA we'd
love to have your input.
Have experience with both, more CUDA than OpenCL though. Feel
free t
On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson
wrote:
If you have any experience with either OpenCL or CUDA we'd love
to have your input.
Have experience with both, more CUDA than OpenCL though. Feel
free to contact me.
On Friday, 28 October 2016 at 16:14:56 UTC, Sameer Pradhan wrote:
I must plead ignorance on the finer interface details, but from
what I am reading this seems like an amazing development. I am
so happy that that D has a solid base for GPU work.
The post from a few weeks back with performance
On Friday, 28 October 2016 at 06:31:19 UTC, Ilya Yaroshenko wrote:
On Friday, 28 October 2016 at 03:44:05 UTC, Andrei Alexandrescu
wrote:
On 10/27/16 3:59 AM, Ilya Yaroshenko wrote:
[...]
I must plead ignorance on the finer interface details, but from
what I am reading this seems like an ama
On Friday, 28 October 2016 at 03:44:05 UTC, Andrei Alexandrescu
wrote:
On 10/27/16 3:59 AM, Ilya Yaroshenko wrote:
Mir GLAS (Generic Linear Algebra Subprograms) has its own
repository [1]
now.
Big news:
1. Mir GLAS does not require D / C++ runtime and can be used
in any
programming language
On 10/27/16 3:59 AM, Ilya Yaroshenko wrote:
Mir GLAS (Generic Linear Algebra Subprograms) has its own repository [1]
now.
Big news:
1. Mir GLAS does not require D / C++ runtime and can be used in any
programming language as common C library! See read README [1] for more
details.
Cool work!
O
On 10/26/2016 12:59 PM, Ilya Yaroshenko wrote:
Mir GLAS (Generic Linear Algebra Subprograms)
Ilya is giving a talk in about 5 hours on D runtime infrastructure which
Mir GLAS is a proof of concept of:
http://forum.dlang.org/thread/nu8qq8$2i1a$1...@digitalmars.com
Ali
Please wait around a year after the last major breaking api change.
Its the kind of library that will be severely limited by Phobos
requirements. After all by your own post, the API still needs a lot of
work done to it and this way it can mature up nicely.
On Wednesday, 26 October 2016 at 20:23:01 UTC, jmh530 wrote:
On Wednesday, 26 October 2016 at 19:59:21 UTC, Ilya Yaroshenko
wrote:
Thanks!
On Wednesday, 26 October 2016 at 19:59:21 UTC, Ilya Yaroshenko
wrote:
Mir GLAS (Generic Linear Algebra Subprograms) has its own
repository [1] now.
Keep up the good work!
On the read-me page, I have a few suggestions for improvements.
The installation section could use some improvement. Most
Mir GLAS (Generic Linear Algebra Subprograms) has its own
repository [1] now.
Big news:
1. Mir GLAS does not require D / C++ runtime and can be used in
any programming language as common C library! See read README [1]
for more details.
2. Netlib's BLAS test suite are part of CI testin
On Monday, 24 October 2016 at 18:45:36 UTC, Jacob Carlborg wrote:
On 2016-10-24 14:37, Andrei Alexandrescu wrote:
Cool, mine is quite similar (I don't use mc so I use RPS1).
One extra
thing I found useful is to display the running time of the
last command
if longer than 1 second. -- Andrei
On 2016-10-24 14:37, Andrei Alexandrescu wrote:
Cool, mine is quite similar (I don't use mc so I use RPS1). One extra
thing I found useful is to display the running time of the last command
if longer than 1 second. -- Andrei
What do you do if it takes longer than 1 second to build the prompt ;
On 10/23/2016 05:58 PM, Vladimir Panteleev wrote:
On Sunday, 23 October 2016 at 21:52:26 UTC, Jonathan M Davis wrote:
LOL. This was too funny not to share. I had a unittest failure in a
project that I'm working on, and dub ended up just printing out
Nice story, thanks for sharing :)
You can c
ple is not only easier to hit than yours, but it's also worse
because even the exit code will report "A-ok!".
These are all examples of why I was always opposed from the beginning to
D's default of "no output unless a test fails": Because it makes
"success"
On Sunday, October 23, 2016 21:58:30 Vladimir Panteleev via Digitalmars-d
wrote:
> You can change your shell prompt so it displays the exit code of
> the last command. It's something frequently seen in people's
> custom prompts. (Here's mine:
> https://github.com/CyberShadow/cyberzshadow)
Wow, th
On Sunday, 23 October 2016 at 21:52:26 UTC, Jonathan M Davis
wrote:
LOL. This was too funny not to share. I had a unittest failure
in a project that I'm working on, and dub ended up just
printing out
Nice story, thanks for sharing :)
You can change your shell prompt so it displays the exit co
rying to see if anyone
else had seen a similar problem and which version of dub the problems
started in (since I was sure that I'd see proper test failure output from
dub previously), and finally I figured out that no, dub didn't have a bug.
Rather, it looked like dmd or druntime did, beca
On Sunday, 15 May 2016 at 14:08:57 UTC, Joseph Rushton Wakeling
wrote:
(2) It's probably more idiomatic to use `void[]` for buffers of
binary data, although I imagine you may have some reasons for
using `ubyte[]` ... ?
curious about this. https://dlang.org/phobos/std_outbuffer.html
defines:
On 2016-09-02 21:52, Dicebot wrote:
Then we perfectly understand each other and I will vote against
introducing any other way/syntax for writing _unit_ tests in D with all
my passion.
This discussion is just going in circles, meeting adjourned.
--
/Jacob Carlborg
On Friday, 2 September 2016 at 19:26:41 UTC, Jacob Carlborg wrote:
On 2016-09-01 14:02, Dicebot wrote:
What would be different? List of unit test blocks available in
the program?
How the unit tests are written and collected.
unittest { assert(true); }
class FooTest : Test
{
void
On 2016-09-01 14:02, Dicebot wrote:
What would be different? List of unit test blocks available in the program?
How the unit tests are written and collected.
unittest { assert(true); }
class FooTest : Test
{
void testFoo() { assert(true); }
}
describe("foo", {
it("
vely import all modules from `main` and recursive
compile-time visiting of all symbols would miss them.
[snip]
Not a problem, since you can do things like this:
It is exactly _THE_ problem. You can't have the imaginary test
runner to reliably find all tests automatically, at least all
c
on't transitively import
>> all modules from `main` and recursive compile-time visiting of all
>> symbols would miss them.
>>
>>> [snip]
>
> Not a problem, since you can do things like this:
It is exactly _THE_ problem. You can't have the imaginary test
On Thursday, 1 September 2016 at 12:06:21 UTC, Dicebot wrote:
On 08/31/2016 01:01 PM, Atila Neves wrote:
And never mind that any such low level library would suffer
from the same problem unit-threaded did until dub fixed it: D
can't reflect on packages so a program must be written that
explici
Unless we force everyone to use dub.
To me it feels like mandatory per-requisite for any test runner changes
in druntime right now is to:
1) make compiler emit runtime info on test block basis instead of per module
2) store TypeInfo of unittest block attributes as part of that runtime info
signature.asc
Description: OpenPGP digital signature
On 08/30/2016 10:40 PM, Jacob Carlborg wrote:
> On 2016-08-30 18:31, Dicebot wrote:
>
>> I definitely wouldn't want to use API like you proposed if I was to
>> write my own test runner. Minimal common ground which would be cool to
>> have is getting range/array of
On Wednesday, 24 August 2016 at 13:52:43 UTC, Andrei Alexandrescu
wrote:
// This will always be true
assert(a >= 1 && a <= 5);
assert(a >= 0.0 && a <= 10.0);
Pretty sure you have a bug here :)
On 2016-08-31 12:06, Atila Neves wrote:
Right now I think you're right and the compiler needs to know. But let
me see what I can do about it with the language we have now.
Or using AST macros :)
--
/Jacob Carlborg
essage (or match it
against a regex); otherwise the test could fail accidentally for
totally unrelated reasons, and nobody would notice...
On Tuesday, 30 August 2016 at 15:45:26 UTC, Andrei Alexandrescu
wrote:
On 08/30/2016 10:44 AM, Atila Neves wrote:
I'd much rather have `assert` be magical or have AST macros to
make the
syntax for writing tests better than what it is now.
Same here. BTW I'd like unittests that "must not compi
On Tuesday, 30 August 2016 at 16:31:56 UTC, Dicebot wrote:
On 08/30/2016 07:17 PM, Jacob Carlborg wrote:
The reason to put in the druntime is because that's where the
existing runner is located.
The advantage of this low level library is that:
* Third party unit test library don'
On 2016-08-30 18:31, Dicebot wrote:
I definitely wouldn't want to use API like you proposed if I was to
write my own test runner. Minimal common ground which would be cool to
have is getting range/array of all unittest blocks together with their
annotations. Anything more than that is opt
On 08/30/2016 01:12 PM, jmh530 wrote:
On Tuesday, 30 August 2016 at 16:18:30 UTC, Jacob Carlborg wrote:
On 2016-08-30 18:17, Seb wrote:
There is a bit of work on a closely related topic on the wiki:
https://wiki.dlang.org/DIP83
Or https://wiki.dlang.org/DIP50 :)
Or that unit-threaded's @S
On Tuesday, 30 August 2016 at 16:18:30 UTC, Jacob Carlborg wrote:
On 2016-08-30 18:17, Seb wrote:
There is a bit of work on a closely related topic on the wiki:
https://wiki.dlang.org/DIP83
Or https://wiki.dlang.org/DIP50 :)
Or that unit-threaded's @ShouldFail seems very similar to
Andrei
On 08/30/2016 07:17 PM, Jacob Carlborg wrote:
> The reason to put in the druntime is because that's where the existing
> runner is located.
>
> The advantage of this low level library is that:
>
> * Third party unit test library don't need to reinvent the wheel
>
On 2016-08-30 18:17, Seb wrote:
There is a bit of work on a closely related topic on the wiki:
https://wiki.dlang.org/DIP83
Or https://wiki.dlang.org/DIP50 :)
--
/Jacob Carlborg
On Tuesday, 30 August 2016 at 16:06:21 UTC, Jacob Carlborg wrote:
I'd much rather have `assert` be magical or have AST macros to
make the
syntax for writing tests better than what it is now.
That would be nice to have.
There is a bit of work on a closely related topic on the wiki:
https://w
On 2016-08-30 16:54, Dicebot wrote:
Definitely not in druntime. Optional extra test runners in Phobos (or
libraries for higher level test suites) are reasonable but I don't want
any changes to fundamentals of how _unit_ tests are defined and used.
You both are kind of missing the point.
On 2016-08-30 16:44, Atila Neves wrote:
I'm obviously very biased but having written a unit testing library that
I'm happy with and proud of I'd just use that instead. I wouldn't be
interested in this.
The point of this low level library is that a high level unit test
lib
On 08/30/2016 10:44 AM, Atila Neves wrote:
I'd much rather have `assert` be magical or have AST macros to make the
syntax for writing tests better than what it is now.
Same here. BTW I'd like unittests that "must not compile" and unittests
that "must fail dynamically".
For the former case, t
Definitely not in druntime. Optional extra test runners in Phobos (or
libraries for higher level test suites) are reasonable but I don't want
any changes to fundamentals of how _unit_ tests are defined and used.
signature.asc
Description: OpenPGP digital signature
On Friday, 26 August 2016 at 17:13:23 UTC, Jacob Carlborg wrote:
I've been thinking lately about unit tests in D. The built-in
support is a bit lacking. There's been many threads with this
topic, even an attempt to get unit-threaded (or parts of it)
into druntime/Phobos.
[...]
I'm obviously
/fscheck-0-2/,
etc. Some of the Phobos tests I wrote use it (and virtually all
of my current code e.g. on median computation), and when they
fail I just print the seed of the RNG and then hardcode it to
reproduce the test. -- Andrei
unit-threaded has had QuickCheck-like property-based testing
I've been thinking lately about unit tests in D. The built-in support is
a bit lacking. There's been many threads with this topic, even an
attempt to get unit-threaded (or parts of it) into druntime/Phobos.
I was thinking, instead of trying to come up with a unit test framework
On 08/24/2016 10:41 AM, H. S. Teoh via Digitalmars-d wrote:
Just a side note: this depends on the assumption that the PRNG is
explicitly chosen, or that the default PRNG will never change;
Correctamundo, it should be explicitly chosen. -- Andrei
On 08/24/2016 10:40 AM, Robert burner Schadek wrote:
Lets move that back to https://github.com/dlang/phobos/pull/2995
D'accordo. -- Andrei
oduce the test.
> -- Andrei
Just a side note: this depends on the assumption that the PRNG is
explicitly chosen, or that the default PRNG will never change; and that
the implementation of the RNG is independent of environmental factors
(such as different CPU's resulting in different answers
Lets move that back to https://github.com/dlang/phobos/pull/2995
://blogs.msdn.microsoft.com/dsyme/2008/08/08/fscheck-0-2/, etc.
Some of the Phobos tests I wrote use it (and virtually all of my
current code e.g. on median computation), and when they fail I just
print the seed of the RNG and then hardcode it to reproduce the test.
-- Andrei
Do you remember that there is a
/fscheck-0-2/,
etc. Some of the Phobos tests I wrote use it (and virtually all
of my current code e.g. on median computation), and when they
fail I just print the seed of the RNG and then hardcode it to
reproduce the test. -- Andrei
Do you remember that there is a pending PR for this at Phobos
all of my current
code e.g. on median computation), and when they fail I just print the
seed of the RNG and then hardcode it to reproduce the test. -- Andrei
On 08/24/2016 01:44 AM, Edwin van Leeuwen wrote:
On Tuesday, 23 August 2016 at 17:55:41 UTC, Andrei Alexandrescu wrote:
Why does "dub test" rebuild the library? It should just re-run
unittests. -- Andrei
To be honest I prefer it to rebuild it. Why would you want to rerun the
tests
On Wednesday, 24 August 2016 at 06:32:54 UTC, Jacob Carlborg
wrote:
Sure, but one might not figure why a test is failing after only
a single run. One might use "dub test" to run integration tests
that depends on some external dependency that is causing the
test to fail.
I always
On 2016-08-24 07:44, Edwin van Leeuwen wrote:
To be honest I prefer it to rebuild it. Why would you want to rerun the
tests without a rebuild? It should give the same failure/success as last
time.
Sure, but one might not figure why a test is failing after only a single
run. One might use
On Tuesday, 23 August 2016 at 17:55:41 UTC, Andrei Alexandrescu
wrote:
Why does "dub test" rebuild the library? It should just re-run
unittests. -- Andrei
To be honest I prefer it to rebuild it. Why would you want to
rerun the tests without a rebuild? It should give the same
failu
On Tuesday, 23 August 2016 at 21:51:57 UTC, John Colvin wrote:
On Tuesday, 23 August 2016 at 20:26:12 UTC, Andrei Alexandrescu
wrote:
As Walter would say, if it's not in bugzilla it will never be
fixed ;)
https://issues.dlang.org/show_bug.cgi?id=16422 -- Andrei
https://github.com/dlang/dub/i
On Tuesday, 23 August 2016 at 20:26:12 UTC, Andrei Alexandrescu
wrote:
As Walter would say, if it's not in bugzilla it will never be
fixed ;)
https://issues.dlang.org/show_bug.cgi?id=16422 -- Andrei
https://github.com/dlang/dub/issues is full of existing issues,
not sure whether it's best to
On 08/23/2016 04:06 PM, Jacob Carlborg wrote:
On 2016-08-23 21:26, Andrei Alexandrescu wrote:
On 08/23/2016 03:14 PM, Jacob Carlborg wrote:
On 2016-08-23 19:55, Andrei Alexandrescu wrote:
Why does "dub test" rebuild the library? It should just re-run
unittests. -- Andrei
Rebuil
On 2016-08-23 21:26, Andrei Alexandrescu wrote:
On 08/23/2016 03:14 PM, Jacob Carlborg wrote:
On 2016-08-23 19:55, Andrei Alexandrescu wrote:
Why does "dub test" rebuild the library? It should just re-run
unittests. -- Andrei
Rebuilds it with unit tests enabled? You can the "
On 08/23/2016 03:14 PM, Jacob Carlborg wrote:
On 2016-08-23 19:55, Andrei Alexandrescu wrote:
Why does "dub test" rebuild the library? It should just re-run
unittests. -- Andrei
Rebuilds it with unit tests enabled? You can the "--verbose" and/or the
"--vverbose&quo
On 2016-08-23 19:55, Andrei Alexandrescu wrote:
Why does "dub test" rebuild the library? It should just re-run
unittests. -- Andrei
Rebuilds it with unit tests enabled? You can the "--verbose" and/or the
"--vverbose" to see exactly the commands that Dub are running.
--
/Jacob Carlborg
Why does "dub test" rebuild the library? It should just re-run
unittests. -- Andrei
wouldn't have caught this bug, as
the corner case test did exercise all of the opSlice function
that had the off-by-one bug. It just did so with test input that
happened to pass anyway.
On Thursday, 7 July 2016 at 08:27:58 UTC, Joakim wrote:
Moral of the story: always check the happy path with your
tests. It's easy to get caught up in all the corner cases,
just don't forget the happy path.
Isn't the moral that we should start to check code coverage for
PRs and alert review
On 07/07/2016 04:27 AM, Joakim wrote:
Dan recently found an off-by-one bug in std.conv.toChars from Phobos,
that somehow wasn't surfaced by our tests:
Nice! Worth a blog entry? -- Andrei
Dan recently found an off-by-one bug in std.conv.toChars from
Phobos, that somehow wasn't surfaced by our tests:
https://issues.dlang.org/show_bug.cgi?id=16192
I looked into why this opSlice test
assert(r[1..2].array == "0");
wasn't triggering it, thought I'd writ
On Saturday, 14 May 2016 at 15:25:58 UTC, Brian wrote:
Project:
https://github.com/putao-dev/google-flatbuffers
Pull address:
https://github.com/google/flatbuffers/pull/3856
dub project:
http://code.dlang.org/packages/flatbuffers
Nice to see someone working on this! A few general bits of
fe
On Saturday, 14 May 2016 at 15:25:58 UTC, Brian wrote:
Project:
https://github.com/putao-dev/google-flatbuffers
Pull address:
https://github.com/google/flatbuffers/pull/3856
dub project:
http://code.dlang.org/packages/flatbuffers
Great!
Project:
https://github.com/putao-dev/google-flatbuffers
Pull address:
https://github.com/google/flatbuffers/pull/3856
dub project:
http://code.dlang.org/packages/flatbuffers
Hello world!!
1 - 100 of 291 matches
Mail list logo
