On Tuesday, 15 April 2014 at 06:31:02 UTC, Andrei Alexandrescu
wrote:
We've just enabled warnings as errors in our build system at
work and suddenly:
Warning: explicit element-wise assignment exprnew is better
than expr
where exprnew and expr are expressions picked from the
code. For
I think @safe guarantees are much stronger if you _start_ with
@safe main and only interact with system code via small @trusted
gateways. If it is @system code calling @safe, low-level trickery
it allows is just too powerful to avoid with reasonably fast
checks.
On Tuesday, 15 April 2014 at 11:23:30 UTC, monarch_dodra wrote:
On Tuesday, 15 April 2014 at 06:31:02 UTC, Andrei Alexandrescu
wrote:
We've just enabled warnings as errors in our build system at
work and suddenly:
Warning: explicit element-wise assignment exprnew is better
than expr
where
On Tuesday, 15 April 2014 at 19:12:30 UTC, Steven Schveighoffer
wrote:
int isthisok(int x, int y) @nogc
{
// need scratch space
int[] buf = new int[x * y];
scope(exit) GC.free(buf.ptr);
// perform some algorithm using buf
...
//
return buf[$-1];
}
Valid?
No way. This can
On Wednesday, 16 April 2014 at 14:16:30 UTC, Bienlein wrote:
On Wednesday, 16 April 2014 at 14:06:13 UTC, Sönke Ludwig wrote:
I agree, but I also wonder why you still keep ignoring vibe.d.
It achieves exactly that - right now! Integration with
std.concurrency would be great, but at least for
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
OK, a bit late to the thread, seeing how it has already went to
ARC off-topic domain :( An attempt to get back to the
On Thursday, 17 April 2014 at 15:39:38 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 15:02:27 UTC, Dicebot wrote:
void foo(OutputRange buffer)
{
buffer.put(42);
}
`foo` can't be @nogc here if OutputRange uses GC as backing
allocator. However I'd really like to use it to
On Thursday, 17 April 2014 at 15:48:29 UTC, bearophile wrote:
Ola Fosheim Grøstad:
Where this falls apart is when you introduce a compacting GC
and the @nogc code is run in a real time priority thread. Then
you need both @nogc_function_calls and @nogc_memory .
Perhaps the @nogc proposal is
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright wrote:
With current limitations @nogc is only useful to verify that
embedded code which
does not have GC at all does not use any GC-triggering
language features before
it comes to weird linker errors / rt-asserts. But that does
not work
On Thursday, 17 April 2014 at 17:48:39 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 15:49:44 UTC, Dicebot wrote:
put() may call GC to grow the buffer, this is the very point.
What is desired is to check if anything _else_ does call GC,
thus the weak @nogc parallel.
What do
On Thursday, 17 April 2014 at 18:18:49 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 18:00:25 UTC, Dicebot wrote:
Such weak @nogc could help to avoid triggering allocations by
an accident and encourage usage of output ranges / buffers.
Ok, more like a lintish feature of the
On Thursday, 17 April 2014 at 22:04:17 UTC, Walter Bright wrote:
On 4/17/2014 1:03 PM, John Colvin wrote:
E.g. you can implement some complicated function foo that
writes to a
user-provided output range and guarantee that all GC usage is
in the control of
the caller and his output range.
As
On Saturday, 19 April 2014 at 14:21:23 UTC, Iain Buclaw via
Digitalmars-d wrote:
eg:
- nothrow has *no* guarantee, period, because it still allows
unrecoverable errors being thrown, and allows people to catch
said
unrecoverable errors.
Hm, it is hard to find clear answer in spec but I
On Saturday, 19 April 2014 at 15:00:26 UTC, Iain Buclaw via
Digitalmars-d wrote:
Nope. I can't recall the exact code, but an example is in the
testsuite. It was discovered when porting to ARM, which was
found to
omit unwind directives for D nothrow functions, causing runtime
hangs
when said
On Saturday, 19 April 2014 at 17:41:58 UTC, Walter Bright wrote:
On 4/19/2014 6:14 AM, Dicebot wrote:
On Thursday, 17 April 2014 at 22:04:17 UTC, Walter Bright
wrote:
On 4/17/2014 1:03 PM, John Colvin wrote:
E.g. you can implement some complicated function foo that
writes to a
user-provided
On Saturday, 19 April 2014 at 18:12:32 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 19 April 2014 at 18:05:48 UTC, Dicebot wrote:
In lot of standard library functions you may actually need to
allocate as part of algorithm, strict @nogc is not applicable
there. However, it is still extremely
On Monday, 21 April 2014 at 15:48:45 UTC, Aleksandar Ruzicic
wrote:
On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu
wrote:
On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
I'm planning to start working on this as soon as I get
approval
from Walter/Andrei, and as most of people who
On Sunday, 20 April 2014 at 18:48:49 UTC, John Colvin wrote:
The way I understood your idea, was that a template could be
marked @nogc, and yet still allow template arguments that
themselves may gc.
This can be accomplished by creating a unit test that passes
non-allocating template
On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:
On 21/04/14 23:33, Dicebot wrote:
I think it is very important to dogfood here and add any
currently
missing dependencies as dub packages instead.
Unless we can use libsass, I would say it's not very productive
to implement a
On Tuesday, 22 April 2014 at 21:21:13 UTC, Aleksandar Ruzicic
wrote:
On Tuesday, 22 April 2014 at 12:27:23 UTC, Dicebot wrote:
On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg
wrote:
On 21/04/14 23:33, Dicebot wrote:
I think it is very important to dogfood here and add any
currently
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu
wrote:
... first hit is
http://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-reading-digital-vs-printed
pointing to a study indicating 95 characters per line as
optimal for on-screen reading
On Thursday, 24 April 2014 at 08:06:18 UTC, Alix Pexton wrote:
On 23/04/2014 5:28 PM, Dicebot wrote:
Gosh now I finally know what researches to blame for my eyes
bleeding
upon most web site restylings (Facebook *caugh-caugh*).
Are you sure that your eyes aren't bleeding because your fonts
On Thursday, 24 April 2014 at 06:13:31 UTC, Jon Giddy wrote:
The file uses a static module constructor to display a run-time
warning. Since the file simply imports the new module, there
isn't anywhere to hang a deprecated attribute, to trigger a
compile-time warning/error.
I don't know of a
On Tuesday, 22 April 2014 at 06:39:47 UTC, Jacob Carlborg wrote:
On 21/04/14 10:49, Lars T. Kyllingstad wrote:
Ok, so any number was poorly phrased. What I meant was a
large
number, because in my experience, modules tend to be quite
large.
Specifically, they are rarely limited to containing
On Thursday, 24 April 2014 at 14:15:45 UTC, Orvid King wrote:
On Thursday, 24 April 2014 at 10:14:07 UTC, Kagamin wrote:
On Wednesday, 23 April 2014 at 18:35:26 UTC, Messenger wrote:
On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote:
After all of that, I intend to include a base
On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 08:21:38 -0400, David Nadlinger
c...@klickverbot.at wrote:
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
One interesting thing about this is that the compiler
implementation may
On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer
wrote:
It is unacceptable to have code that fails with one compiler
and works with the other despite the shared frontend version.
Such enhanced @nogc attributes must be placed into
compiler-specific attribute space and not as a
On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot pub...@dicebot.lv
Which is the very reason why I was so insisting of defining
exact set of cases when optimisation is to be guaranteed in
spec (before releasing @nogc).
On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Best practices in C++ code increasingly means putting functions
and declarations in namespaces. Currently, there is no support
in D to call C++ functions in namespaces. The primary issue is
that the
On Saturday, 26 April 2014 at 18:11:18 UTC, Walter Bright wrote:
On 4/26/2014 4:57 AM, Dicebot wrote:
Necessity to define namespaces for
interfacing with C++ must not result in usage of namespaces of
pure D code.
Why?
I don't see much of any use for namespaces in pure D code,
though I
On Saturday, 26 April 2014 at 15:19:55 UTC, Timon Gehr wrote:
On 04/26/2014 01:57 PM, Dicebot wrote:
I think this is a very bad proposal. Necessity to define
namespaces for
interfacing with C++ must not result in usage of namespaces of
pure D code.
Well, the proposed feature does not add
On Saturday, 26 April 2014 at 18:18:39 UTC, Walter Bright wrote:
On 4/26/2014 7:38 AM, Daniel Murphy wrote:
So, people didn't like the proposal last time you made the
thread, so you made
it again? My objections from the last thread still stand.
Mangling is all we
need, just add a pragma or
On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright wrote:
On 4/26/2014 1:06 PM, Jacob Carlborg wrote:
BTW, can't we just handle this automatically in a tool like
DStep, with the help
of pragma(mangle).
Just setting the name mangling is not enough. There's also the
issue of how does
On Saturday, 26 April 2014 at 18:52:41 UTC, Walter Bright wrote:
On 4/26/2014 11:30 AM, Dicebot wrote:
Compromise - consider namespace definition from extern(C++)
during name
resolution. But still keep actual feature tied to
extern(C++) to keep its use
case clear.
I mentioned something
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
On 04/26/2014 09:27 PM, Daniel Murphy wrote:
We already have a feature to manage conflicts and organisation
in D code - modules!
Named mixin templates are a much closer fit.
Using named mixin templates for pure scope resolution
On Saturday, 26 April 2014 at 23:05:23 UTC, Timon Gehr wrote:
On 04/27/2014 12:43 AM, Dicebot wrote:
On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote:
On 04/26/2014 09:27 PM, Daniel Murphy wrote:
We already have a feature to manage conflicts and
organisation in D
code -
On Saturday, 26 April 2014 at 23:35:44 UTC, Walter Bright wrote:
On 4/26/2014 2:45 PM, Dicebot wrote:
On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright
wrote:
On 4/26/2014 1:06 PM, Jacob Carlborg wrote:
BTW, can't we just handle this automatically in a tool like
DStep, with the help
On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
Since the namespace keyword doesn't seem to be gaining much
traction, an alternative syntax would be:
extern (C++, N.M) { void foo(); }
which would be semantically equivalent to the previous:
extern (C++) namespace N {
On Sunday, 27 April 2014 at 08:16:58 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/27/14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Using named mixin templates for pure scope resolution is side
effect and should be discouraged in any reasonable code.
There's also
On Sunday, 27 April 2014 at 13:43:13 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/27/14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I believe this is a temporary workaround. Once bugs and
deficiencies of existing module system will be taken care of,
there won't be any
On Sunday, 27 April 2014 at 13:49:15 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/27/14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
This pops up very often so I have just went and implemented
proof
of concept for package(pkg1.pkg2.pkg3) protection attribute
syntax
On Monday, 28 April 2014 at 13:20:19 UTC, Steven Schveighoffer
wrote:
On Mon, 28 Apr 2014 04:10:34 -0400, Andrej Mitrovic via
Digitalmars-d digitalmars-d@puremagic.com wrote:
On 4/27/14, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
When you find yourself doing things
On Monday, 28 April 2014 at 13:54:05 UTC, Steven Schveighoffer
wrote:
On Mon, 28 Apr 2014 09:23:17 -0400, Dicebot pub...@dicebot.lv
wrote:
On Monday, 28 April 2014 at 13:20:19 UTC, Steven Schveighoffer
wrote:
And actually, this would have to be std.clock.currTime
On Monday, 28 April 2014 at 15:19:26 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 4/28/14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Yeah, it is just a random idea I have just had.
I'm afraid you're 7 years too late for that patent. :P
https://issues.dlang.org
On Monday, 28 April 2014 at 14:27:19 UTC, Steven Schveighoffer
wrote:
void main()
{
func(); // error
foo.func(); // ALSO error
bar.func(); // Not error, BUT it's actually calling
foo::func from C++ land!
}
I don't see any fundamental issue here because you can still use
renamed
On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole
wrote:
On Tuesday, 29 April 2014 at 14:41:19 UTC, James wrote:
I have a friend that is a web developer. I, however want to
collaborate with him, so I am trying to get him to learn D. I
don't know how to persuade him! How can D be
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
On Tue, 2014-04-29 at 22:09 +, Adam D. Ruppe via
Digitalmars-d
wrote:
[…]
I can just get stuff done in D in a fraction of a time it
takes to do even less in RoR.
This is the stuff marketing campaigns are
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
But unit tests in D suck as well. I mean, how do I run a single
unit test in D?
This is common complaint I still fail to understand. I have never
ever wanted to run a single unit test, why would one need it? If
running all
On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole
wrote:
Having a quick look at Cmsed I must admit I like plain vibe.d
much more despite the added features :( Forced module coupling
and OO-heavy design is big loss compared to design simplicity
and independence of base vibe.d
On Wednesday, 30 April 2014 at 11:20:40 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote:
walkLength is a really good name. Clear, concise, to the
point. It's not often that you can make such a short name that
explains the behaviour so well.
On Wednesday, 30 April 2014 at 11:35:56 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 30 April 2014 at 11:24:09 UTC, Dicebot wrote:
For algorithms execution complexity is not a mere
implementation detail. walk' implies exactly that it is O(n)
as opposed to O(1) of built-in length properties.
On Wednesday, 30 April 2014 at 10:01:51 UTC, Rikki Cattermole
wrote:
Why can't stand-alone annotated function be a valid route?
Route is pretty much method + url + handler and first two can
be inferred by convention in many cases (as done in
vibe.web.rest Co).
The only way I know of that
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it as
one of examples for my DConf talk just
On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig
wrote:
When I have a bug in my code I usually add a test for it so it
never happens again.
Because it's a bug, I might need to debug it. So I add a couple
of writefln instead of using a debugger (it's faster and I
get formatted
On Wednesday, 30 April 2014 at 14:58:20 UTC, Ary Borenszweig
wrote:
That's good.
What if you have tests against a database that where each take
some time? I don't want to wait for the whole tests to run...
Tests with I/O are not unit tests. And built-in D feature is not
called
On Wednesday, 30 April 2014 at 16:55:06 UTC, Andrei Alexandrescu
wrote:
Walter and I also discussed static unittest a while ago -
yes, another use of static :o).
A static unittest would be evaluated only during compilation,
and would prove things that fall in the realm of static
checking but
On Wednesday, 30 April 2014 at 17:24:32 UTC, Andrei Alexandrescu
wrote:
On 4/30/14, 10:11 AM, H. S. Teoh via Digitalmars-d wrote:
Yeah, what does static unittest give us beyond static assert?
(Other
than nice syntax, that is.)
static assert is for expressions, static unittest is for
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 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 Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have
never ever
wanted to run a single unit test, why would one need it? If
running all
module tests at once creates problems than
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 Wednesday, 30 April 2014 at 20:36:15 UTC, Andrei Alexandrescu
wrote:
On 4/30/14, 12:25 PM, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg
wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have
never ever
wanted to
On Wednesday, 30 April 2014 at 20:20:26 UTC, Jacob Carlborg wrote:
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.
It
On Wednesday, 30 April 2014 at 21:49:06 UTC, 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, 2014-04-30 at 11:19 -0700, Jonathan M Davis via
Digitalmars-d
wrote:
unittest blocks just
On Thursday, 1 May 2014 at 01:45:21 UTC, Xavier Bigand wrote:
Splitting all features at an absolute atomic level can be
achieve for open-source libraries, but it's pretty much
impossible for an industrial software. Why being so restrictive
when it's possible to support both vision by extending
On Wednesday, 30 April 2014 at 21:09:51 UTC, Átila Neves wrote:
I don't know about anyone else, but I make my tests fail a
lot.
I think this is key difference. For me failing unit test is
always exceptional situation.
I TDD a lot. Tests failing are normal. Not only that, I
refactor a lot
On Thursday, 1 May 2014 at 04:50:30 UTC, Jonathan M Davis via
Digitalmars-d wrote:
std.file's unit tests would break immediately. It wouldn't
surprise me
if std.socket's unit tests broke. std.datetime's unit tests
would
probably break on Posix systems, because some of them
temporarily set
the
On Thursday, 1 May 2014 at 07:32:43 UTC, bearophile wrote:
This is just the basic idea, and perhaps people suggested
something better than this.
Bye,
bearophile
Yeah I sometimes have commented out main() for that purpose.
Sounds like a useful generic addition.
On Thursday, 1 May 2014 at 07:47:27 UTC, Jonathan M Davis via
Digitalmars-d wrote:
Honestly, I see no problem with std.file's unit tests
triggering I/O.
That's what the module _does_. And it specifically uses the
system's
temp directory so that it doesn't screw with anything else on
the
On Thursday, 1 May 2014 at 08:51:47 UTC, Johannes Pfau wrote:
Am Wed, 30 Apr 2014 22:19:24 +0200
schrieb Jacob Carlborg d...@me.com:
__traits(getUnitTests)
I've always wondered, but never asked: Doesn't
__traits(getUnitTests)
usage suffer from the same problem std.benchmark had?
That in
On Thursday, 1 May 2014 at 08:51:47 UTC, Johannes Pfau wrote:
Am Wed, 30 Apr 2014 22:19:24 +0200
schrieb Jacob Carlborg d...@me.com:
__traits(getUnitTests)
I've always wondered, but never asked: Doesn't
__traits(getUnitTests)
usage suffer from the same problem std.benchmark had?
That in
On Thursday, 1 May 2014 at 12:17:56 UTC, Ary Borenszweig wrote:
On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
This cannot be a good idea. If the block says unittest then
it contains
unit tests, not integration tests or system tests, just
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 internal
projects removing
all accidental I/O tests for the very reason that /tmp was full
Well a bunch of stuff will not work on a full /tmp.
On Thursday, 1 May 2014 at 12:04:57 UTC, Xavier Bigand wrote:
It's just a lot harder when you are under pressure.
I am working for a very small company and our dead lines
clearly doesn't help us with that, and because I am in the
video game industry it's not really critical to have small bugs.
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 internal
projects removing
all accidental
On Monday, 5 May 2014 at 12:48:11 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Mon, 05 May 2014 15:55:13 +0400
Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Why the heck should internal symbols conflict with public from
other
modules? No idea.
Because no one has
On Monday, 5 May 2014 at 13:33:13 UTC, Jonathan M Davis via
Digitalmars-d wrote:
IIRC, it had something to do with member functions, but I'd
have to go digging
through the newsgroup archives for the details. In general
though, I think
that private symbols should be ignored by everything outside
Initial post in this thread makes focus on a change that does not
fix anything and implies silent semantical breakage. I am glad
Andrei has reconsidered it but feels like key problem is not that
proposal itself was bad but that it does not even try to solve.
Real issue being deterministic
Very short feedback about original proposal:
1) managing local objects is not really a problem, we already
have `scoped` in Phobos for that (and unimplemented scope
qualifier as possible more reliable approach)
2) real problem is managing global objects without clear
destruction point while
On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu
wrote:
It got full because of tests (surprise!). Your actions?
Fix the machine and reduce the output created by the unittests.
It's a simple engineering problem. -- Andrei
You can't. You have not control over that machine you
On Thursday, 1 May 2014 at 19:22:36 UTC, 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
On Monday, 5 May 2014 at 15:36:19 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:11 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu
wrote:
It got full because of tests (surprise!). Your actions?
Fix the machine and reduce the output created by the
unittests.
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no I/O
because
any sort of I/O can fail because of reasons you don't control
from the
test suite is an appropriate generalization of my
On Monday, 5 May 2014 at 17:22:58 UTC, Marco Leise wrote:
Am Mon, 5 May 2014 09:39:30 -0700
schrieb H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com:
On Mon, May 05, 2014 at 03:55:12PM +, bearophile via
Digitalmars-d wrote:
Andrei Alexandrescu:
I think the needs to support
On Saturday, 3 May 2014 at 12:26:13 UTC, Rikki Cattermole wrote:
On Saturday, 3 May 2014 at 12:24:59 UTC, Atila Neves wrote:
Out of curiosity are you on Windows?
No, Arch Linux 64-bit. I also just noticed a glaring threading
bug in my code as well that somehow's never turned up. This is
not
On Monday, 5 May 2014 at 18:24:43 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 10:08 AM, Dicebot wrote:
On Monday, 5 May 2014 at 16:33:42 UTC, Andrei Alexandrescu
wrote:
On 5/5/14, 8:55 AM, Dicebot wrote:
It was just a most simple example. Unittests should do no
I/O because
any sort of I/O
On Monday, 5 May 2014 at 18:29:40 UTC, Andrei Alexandrescu wrote:
My understanding here is you're trying to make dogma out of
engineering choices that may vary widely across projects and
organizations. No thanks.
Andrei
I am asking to either suggest an alternative solution or to
clarify
On Tuesday, 6 May 2014 at 15:52:10 UTC, John Colvin wrote:
On Tuesday, 6 May 2014 at 15:48:59 UTC, Andrei Alexandrescu
I can't seem to find simd on our dub site
http://code.dlang.org/search?q=simd. Did you put it there
under another name?
Andrei
I don't think it's there. I would love if it
On Monday, 5 May 2014 at 18:58:37 UTC, Andrei Alexandrescu wrote:
On 5/5/14, 11:47 AM, Dicebot wrote:
On Monday, 5 May 2014 at 18:29:40 UTC, Andrei Alexandrescu
wrote:
My understanding here is you're trying to make dogma out of
engineering choices that may vary widely across projects and
On Tuesday, 6 May 2014 at 15:54:30 UTC, Bruno Medeiros wrote:
But before we continue the discussion, we are missing am more
basic assumption here: Do we want D to have a Unit-Testing
facility, or a Testing facility?? In other words, do we want to
be able to write automated tests that are
It will benefit everyone in D community one way or another.
On Tuesday, 6 May 2014 at 17:57:11 UTC, Manu via Digitalmars-d
wrote:
Which only confirms my suspicion that those who complain about
lack of
experimental Phobos package are likely to simply not use dub.
As I said before, dub has never even occurred to me. No windows
user
is likely to
On Tuesday, 6 May 2014 at 18:13:01 UTC, Andrei Alexandrescu wrote:
On 5/6/14, 10:43 AM, Dicebot wrote:
Disk I/O failure throws Exception which can be easily consumed
somewhere
inside tested control flow resulting in absolutely mysterious
test failures.
If you're pointing out full /tmp/
On Tuesday, 6 May 2014 at 18:28:27 UTC, Jacob Carlborg wrote:
d.
I don't see why would be bad to use unittest for integration
tests, except for the misguided name. It's perfectly to place
unittest is completely different modules and packages. They
don't need to be placed inline.
Well I am
On Wednesday, 7 May 2014 at 06:34:44 UTC, Jacob Carlborg wrote:
So you're saying to use the unittest keyword but with a UDA?
I think this is most reasonable compromise that does not harm
existing system.
Something I already do, but for unit tests. Well my idea for a
testing framework would
On Tuesday, 6 May 2014 at 20:41:01 UTC, Andrei Alexandrescu wrote:
Fail with diagnostic. -- Andrei
..and do that for every single test case which is affected. Which
requires either clear test execution order (including
cross-module test dependencies) or shared boilerplate (which
becomes
On Wednesday, 7 May 2014 at 18:41:17 UTC, Maxime
Chevalier-Boisvert wrote:
Basically, I just want to create a wstring view on an
existing raw buffer that exists in memory somewhere, based on
a pointer to this buffer and its length.
Looks like you actually don't need to allocate anything at
On Wednesday, 7 May 2014 at 16:09:28 UTC, Atila Neves wrote:
They can. But those descriptions are not included in failing
test output. What I think Jacob might be getting to as well is
that assertEquals or the more RSpec-like foo.should equal 3
is more readable than the raw asserts.
The
On Tuesday, 6 May 2014 at 20:41:01 UTC, Andrei Alexandrescu wrote:
On 5/6/14, 11:27 AM, Dicebot wrote:
On Tuesday, 6 May 2014 at 18:13:01 UTC, Andrei Alexandrescu
wrote:
On 5/6/14, 10:43 AM, Dicebot wrote:
Disk I/O failure throws Exception which can be easily
consumed somewhere
inside tested
On Wednesday, 7 May 2014 at 14:34:41 UTC, Bruno Medeiros wrote:
On 06/05/2014 18:58, Dicebot wrote:
I see no good in trying to unite those very different beasts
and my
experience with existing test libraries has been very
unpleasant in that
regard.
What test libraries/frameworks have you
1 - 100 of 2167 matches
Mail list logo
