On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
I've made a simple port of ruby's colorize library for D.
I'd greatly appreciate any feedback. Windows isn't supported,
yet.
Cool! Would it be hard to add windows support?
Windows support added. It relies on a partial ANSI/VT100
Could you help me to get work DCD and DScanner with Sublime in
last version.
I see that after building now I am getting binary with name
DScanner.exe instead of DCD-Server.
How to get them work?
On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote:
On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
I've made a simple port of ruby's colorize library for D.
I'd greatly appreciate any feedback. Windows isn't supported,
yet.
Cool! Would it be hard to add windows support?
Windows
DMD v2.066.0-rc1 binaries are available for testing:
http://wiki.dlang.org/Beta_Testing
On Thursday, 31 July 2014 at 12:09:41 UTC, Suliman wrote:
On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote:
On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
I've made a simple port of ruby's colorize library for D.
I'd greatly appreciate any feedback. Windows isn't supported,
yet.
Am Wed, 30 Jul 2014 17:05:20 +
schrieb David Soria Parra davi...@fb.com:
Hi,
We are happy to announce the release of 'dfuse', a high level D
language binding
for fuse (http://fuse.sourceforge.net). It supports libfuse =
2.8 and works on
both Linux and MacOS (osxfuse). You can find
Am 31.07.2014 16:00, schrieb Johannes Pfau:
Am Wed, 30 Jul 2014 17:05:20 +
schrieb David Soria Parra davi...@fb.com:
Hi,
We are happy to announce the release of 'dfuse', a high level D
language binding
for fuse (http://fuse.sourceforge.net). It supports libfuse =
2.8 and works on
both
On Thursday, 31 July 2014 at 13:45:45 UTC, ponce wrote:
On Thursday, 31 July 2014 at 12:09:41 UTC, Suliman wrote:
On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote:
On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
I've made a simple port of ruby's colorize library for D.
I'd
On Thursday, 31 July 2014 at 17:01:22 UTC, Suliman wrote:
On Thursday, 31 July 2014 at 13:45:45 UTC, ponce wrote:
On Thursday, 31 July 2014 at 12:09:41 UTC, Suliman wrote:
On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote:
On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
I've
Hi,
GDC's revamped site is now live!
http://gdcproject.org
Techy details for those who are interested:
- Uses vibe.d as the web engine.
- Pages are written in markdown and compiled at runtime (separate
thread that watches for file changes).
- Redis memstore backend for caching compiled
On Thursday, 31 July 2014 at 14:02:28 UTC, Johannes Pfau wrote:
Awesome!
Will this be added to code.dlang.org?
There's a question on reddit regarding performance. I'd guess
performance should be quite good in general, but the simple
example
throws/allocates* Exceptions on missing files. Does
On 31 July 2014 18:34, Iain Buclaw via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Hi,
GDC's revamped site is now live!
http://gdcproject.org
See a mistake? Raise a pull request!
https://github.com/D-Programming-GDC/gdcproject
On 31 Jul 2014 19:35, Iain Buclaw via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Hi,
GDC's revamped site is now live!
http://gdcproject.org
Techy details for those who are interested:
- Uses vibe.d as the web engine.
- Pages are written in markdown and compiled
On Saturday, 26 July 2014 at 00:10:50 UTC, Bill Baxter via
Digitalmars-d-announce wrote:
In the YouTube interface, click on the pencil icon (Info
Settings) and
there's a place to set what frame to use as a thumbnail there.
--bb
I don't think it needs to be changed :D
On Tuesday, 29 July 2014 at 13:36:39 UTC, Stefan Koch wrote:
Hello,
I am happy to announce that my 32bit version of sdc compiles
the whole testsuite including mixins.
the only there are only 6 tests still failing
2 of them are dependent on size_t.siezof beeing 8.
The otherer 4 have to do with
On 7/30/2014 10:16 PM, bearophile wrote:
Walter Bright:
Show me a piece of code with different behavior. Start with the array bounds
thing.
People have already shown you code that behaves differently with assert and
assume.
I'd like to see what you are saying is different in a real example.
On 7/30/2014 10:19 PM, bearophile wrote:
Walter Bright:
No, it will break code that already is broken.
I have probably lost the grasp of this part of the discussion. But I don't see
what's broken in using assert to verify that a pointer is not null. Do you think
that pointer comes from
On 29 July 2014 18:34, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
the DMD release cycle takes the rapid out of rapid iteration.
Sad but true.
On 28 July 2014 17:04, w0rp via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 28 July 2014 at 10:27:02 UTC, Iain Buclaw wrote:
Hi,
dlang.org isn't the only site being re-implemented using vibe.d - GDC's
homepage is now getting a UI update.
On Wednesday, 30 July 2014 at 19:50:35 UTC, Jonathan Marler wrote:
I like the discussion. I do want to remind everyone that
OPTLINK is very fast and switching to a different linker will
likely result performance hit.
Wouldn't it be easier to optimize a linker written in D than
tinker with
On 7/30/2014 3:39 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
My take is that, for this reason, these should be asserts and not enforce()
statements. What are your thoughts on the matter?
An excellent question.
First, note that enforce() returns a recoverable exception, and assert()
On 7/30/2014 10:49 PM, Tofu Ninja wrote:
On Thursday, 31 July 2014 at 05:05:33 UTC, Walter Bright wrote:
On 7/30/2014 8:09 PM, Tofu Ninja wrote:
When is the appropriate time to use an assert? If an assert
should not be used on input, then any thing that can't be
statically known is considered
On 07/31/2014 12:01 AM, Walter Bright wrote:
(...)
2. The compiler can make use of assert expressions to improve
optimization, even in -release mode.
(...)
Does this mean that assertions used for optimization will be left in
-release? There's plenty of times where I've had an old incorrect
On Thursday, 31 July 2014 at 06:46:19 UTC, Kagamin wrote:
On Wednesday, 30 July 2014 at 19:50:35 UTC, Jonathan Marler
wrote:
I like the discussion. I do want to remind everyone that
OPTLINK is very fast and switching to a different linker will
likely result performance hit.
Wouldn't it be
On Wednesday, 30 July 2014 at 17:01:39 UTC, Andrei Alexandrescu
wrote:
Yah but the log object, i.e. the thing you log things in (the
paper log on a ship etc) is a log, not a logger. A logger
would be the person writing into the log.
Logging to a paper log is done directly without a logger. A
On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu
wrote:
Yah but then we have stuttering such as log.log(ehm) which is
oddly the same as log(ehm).
log.write
log.writef
On Wednesday, 30 July 2014 at 17:32:40 UTC, Brad Anderson wrote:
What comes to mind for me are micro-tutorials. When I was using
PHP back in the day I'd be trying to do something and I'd find
the function I could use to do it but figuring out exactly how
to make use of the function to
On 7/30/2014 4:05 PM, Ary Borenszweig wrote:
On 7/30/14, 7:01 PM, Walter Bright wrote:
I'd like to sum up my position and intent on all this.
7. using enforce() to check for program bugs is utterly wrong. enforce()
is a library creation, the core language does not recognize it.
What do you
On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright wrote:
I'd like to sum up my position and intent on all this.
1. I can discern no useful, practical difference between the
notions of assume and assert.
People have explained the difference repeatedly, a ridiculous
number of times
On 7/31/2014 12:01 AM, simendsjo wrote:
On 07/31/2014 12:01 AM, Walter Bright wrote:
(...)
2. The compiler can make use of assert expressions to improve
optimization, even in -release mode.
(...)
Does this mean that assertions used for optimization will be left in
-release? There's plenty of
On 7/30/2014 6:16 PM, Dicebot wrote:
On Wednesday, 30 July 2014 at 23:50:51 UTC, H. S. Teoh via Digitalmars-d wrote:
But if you don't want to check ever to be removed, currently you have to
write:
if (!requiredCondition)
assert(0); // compiler never removes this
which IMO is
On Thursday, 31 July 2014 at 07:07:27 UTC, Jonathan Marler wrote:
No matter how much you optimize your D code, you will only ever
be able to use a subset of what assembly can do.
Such micro-optimizations give only marginal contribution to
performance, which is mostly determined by choice of
On 7/30/2014 4:51 PM, Tobias Müller wrote:
With relatively 'dumb' compilers, this is not a big problem, but optimizers
are more and more clever and will take profit of such assumptions if they
can.
If D wishes to be competitive, it must go down that path.
If you, as a user, do not wish this
H. S. Teoh via Digitalmars-d wrote in message
news:mailman.255.1406747871.16021.digitalmar...@puremagic.com...
Wait, what? I thought the whole point of enforce is that it will *not*
be removed by the compiler, no matter what?
No, the compiler is free to remove it if it can prove it will
On 7/31/2014 12:40 AM, David Bregman wrote:
On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright wrote:
I'd like to sum up my position and intent on all this.
1. I can discern no useful, practical difference between the notions of assume
and assert.
People have explained the difference
Walter Bright wrote in message news:lrbpvj$mih$1...@digitalmars.com...
5. assert(0); is equivalent to a halt, and the compiler won't remove it.
This is not the same definition the spec gives. The spec says assert(0) can
be treated as unreachable, and the compiler is allowed to optimize
Daniel Murphy wrote in message news:lrct2d$1me8$1...@digitalmars.com...
Wait, what? I thought the whole point of enforce is that it will *not*
be removed by the compiler, no matter what?
No, the compiler is free to remove it if it can prove it will never be
triggered. eg if the condition
In terms of what they practically do, they have *nothing* in
common, their
functions are entirely orthogonal.
They are inextricably entangled. Consider:
if (x == 0) abort(); // essentially what assert(x) does
... at this point, the optimizer knows, beyond doubt, that
x!=0 ...
On Thursday, 31 July 2014 at 07:47:51 UTC, Walter Bright wrote:
On 7/30/2014 4:51 PM, Tobias Müller wrote:
With relatively 'dumb' compilers, this is not a big problem,
but optimizers
are more and more clever and will take profit of such
assumptions if they
can.
If D wishes to be
Jonathan Marler wrote in message
news:xrpdzjuaxtdhyfhps...@forum.dlang.org...
I like the discussion. I do want to remind everyone that OPTLINK is very
fast and switching to a different linker will likely result performance
hit. There are advantages to using COFF as it seems more compilers
On Wednesday, 30 July 2014 at 18:23:06 UTC, Daniel Murphy wrote:
John Colvin wrote in message
news:oyzjykmvgzdzkprzu...@forum.dlang.org...
Don't use -release.
haha yeah, or that!
debug enforce(...) would also work just fine. It depends if
you're happy with leaving bounds checking
On Thursday, 31 July 2014 at 08:23:44 UTC, Daniel Murphy wrote:
Daniel Murphy wrote in message
news:lrct2d$1me8$1...@digitalmars.com...
Wait, what? I thought the whole point of enforce is that it
will *not*
be removed by the compiler, no matter what?
No, the compiler is free to remove
On Thursday, 31 July 2014 at 07:13:37 UTC, Kagamin wrote:
On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu
wrote:
Yah but then we have stuttering such as log.log(ehm) which
is oddly the same as log(ehm).
log.write
log.writef
And with
alias writef opCall;
(from the
On 7/31/2014 1:27 AM, Tobias Pankrath wrote:
In terms of what they practically do, they have *nothing* in common, their
functions are entirely orthogonal.
They are inextricably entangled. Consider:
if (x == 0) abort(); // essentially what assert(x) does
... at this point, the
On 7/31/2014 1:23 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:lrbpvj$mih$1...@digitalmars.com...
5. assert(0); is equivalent to a halt, and the compiler won't remove it.
This is not the same definition the spec gives. The spec says assert(0) can be
treated as unreachable,
On Thursday, 31 July 2014 at 08:23:44 UTC, Daniel Murphy wrote:
Daniel Murphy wrote in message
news:lrct2d$1me8$1...@digitalmars.com...
Wait, what? I thought the whole point of enforce is that it
will *not*
be removed by the compiler, no matter what?
No, the compiler is free to remove
On Wednesday, 30 July 2014 at 19:17:51 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Jul 30, 2014 at 07:09:41PM +, via Digitalmars-d
wrote:
On Wednesday, 30 July 2014 at 18:25:43 UTC, H. S. Teoh via
Digitalmars-d
wrote:
If you want the check to always be there, use enforce, not
assert.
Walter Bright newshou...@digitalmars.com wrote:
On 7/30/2014 10:16 PM, bearophile wrote:
But you have redefined assert to mean a mix of assume and assert.
I haven't redefined anything. It's always been that way. It's used that
way in C/C++ (see your Microsoft C++ link).
Actually I cannot
On Thursday, 31 July 2014 at 09:13:53 UTC, Walter Bright wrote:
On 7/31/2014 1:23 AM, Daniel Murphy wrote:
Walter Bright wrote in message
news:lrbpvj$mih$1...@digitalmars.com...
5. assert(0); is equivalent to a halt, and the compiler won't
remove it.
This is not the same definition the
On Thursday, 31 July 2014 at 05:56:31 UTC, Walter Bright wrote:
On 7/30/2014 10:16 PM, bearophile wrote:
Walter Bright:
Show me a piece of code with different behavior. Start with
the array bounds
thing.
People have already shown you code that behaves differently
with assert and
assume.
On Thursday, 31 July 2014 at 10:24:07 UTC, ponce wrote:
If I write:
---
switch(expr())
{
case 0: doIt();
case 1: doThat();
default:
assert(0);
}
---
Will the optimizer be able to remove the default: case?
Assuming fall-through (`goto case`), not only the default case.
The entire switch
On Thursday, 31 July 2014 at 08:08:43 UTC, Walter Bright wrote:
On 7/31/2014 12:40 AM, David Bregman wrote:
On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright
wrote:
I'd like to sum up my position and intent on all this.
1. I can discern no useful, practical difference between the
Ola Fosheim Grøstad:
Here is a set of examples of annotated programs that have been
formally proved correct for those interested:
http://toccata.lri.fr/gallery/why3.en.html
More comments:
---
A problem with code like this is that it's drowing in noise. The
Walter Bright:
I'd like to see what you are saying is different in a real
example.
(The problem is that your have defined your own idea, so what I
can show you will look meaningless or not comformant to your own
definition. So this discussion is going nowhere. And my original
topic drowns
In debug builds gets rewritten as:
int max(in int x, in int y) {
if (x = y)
throw new AssertError(...);
return x;
}
Sorry, I meant:
In debug builds gets rewritten as:
int max(in int x, in int y) {
if (x = y)
throw new AssertError(...);
return (x y) ? x : y;
http://tech.esper.com/2014/07/30/algebraic-data-types/
D already has product type it is struct.
But D lacks sum type also called tagged-union.
Do you think it would be possible to add something like this to
D2 ?
On Thursday, 31 July 2014 at 08:36:12 UTC, John Colvin wrote:
Wait what? Now I'm confused.
x y is guaranteed at point B (the assert).
x and y are unchanged between point A (the enforce) and point B.
Therefore, x y is guaranteed at point A
That's not true. If x and y didn't follow x y,
On Thursday, 31 July 2014 at 10:14:06 UTC, Marc Schütz wrote:
On Thursday, 31 July 2014 at 08:23:44 UTC, Daniel Murphy wrote:
Daniel Murphy wrote in message
news:lrct2d$1me8$1...@digitalmars.com...
Wait, what? I thought the whole point of enforce is that it
will *not*
be removed by the
On Thursday, 31 July 2014 at 11:42:21 UTC, Remo wrote:
http://tech.esper.com/2014/07/30/algebraic-data-types/
D already has product type it is struct.
But D lacks sum type also called tagged-union.
Do you think it would be possible to add something like this to
D2 ?
There is a library
On Thursday, 31 July 2014 at 11:42:21 UTC, Remo wrote:
http://tech.esper.com/2014/07/30/algebraic-data-types/
D already has product type it is struct.
But D lacks sum type also called tagged-union.
Do you think it would be possible to add something like this to
D2 ?
I think you're looking
On Thursday, 31 July 2014 at 06:57:15 UTC, Walter Bright wrote:
For LinearCongruentialEngine() and initialize(), passing
invalid arguments are programming bugs, and so they should be
asserting.
Isn't phobos compiled in release mode? And since those asserts
are never compiled, what purpose do
Am 31.07.2014 04:53, schrieb Walter Bright:
On 7/30/2014 6:38 PM, Daniel Gibson wrote:
I'm in favor of a harmless assert().
In C(++) I sometimes use things like
assert(x != NULL);
if(x != NULL) {
x-foo = 42;
// ...
}
I have that assertion to hopefully find bugs during development
Am 31.07.2014 15:32, schrieb Johannes Pfau:
Am Wed, 30 Jul 2014 17:32:10 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 7/30/14, 5:29 PM, Andrei Alexandrescu wrote:
On 7/30/14, 4:51 PM, Tobias Müller wrote:
With relatively 'dumb' compilers, this is not a big problem, but
On Thursday, 31 July 2014 at 11:01:56 UTC, Marc Schütz wrote:
On Thursday, 31 July 2014 at 10:24:07 UTC, ponce wrote:
If I write:
---
switch(expr())
{
case 0: doIt();
case 1: doThat();
default:
assert(0);
}
---
Will the optimizer be able to remove the default: case?
Assuming fall-through
Am Wed, 30 Jul 2014 17:32:10 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 7/30/14, 5:29 PM, Andrei Alexandrescu wrote:
On 7/30/14, 4:51 PM, Tobias Müller wrote:
With relatively 'dumb' compilers, this is not a big problem, but
optimizers
are more and more clever and
Am 31.07.2014 13:42, schrieb Remo:
http://tech.esper.com/2014/07/30/algebraic-data-types/
D already has product type it is struct.
But D lacks sum type also called tagged-union.
Do you think it would be possible to add something like this to D2 ?
I'm currently in the process of polishing one
On Thursday, 31 July 2014 at 07:00:01 UTC, Walter Bright wrote:
On 7/30/2014 10:49 PM, Tofu Ninja wrote:
On Thursday, 31 July 2014 at 05:05:33 UTC, Walter Bright wrote:
On 7/30/2014 8:09 PM, Tofu Ninja wrote:
When is the appropriate time to use an assert? If an assert
should not be used on
On Thu, 31 Jul 2014 11:42:20 +, Remo wrote:
http://tech.esper.com/2014/07/30/algebraic-data-types/
D already has product type it is struct.
But D lacks sum type also called tagged-union.
Do you think it would be possible to add something like this to D2 ?
In addition to the
On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get why anyone would want such an optimization: I want an
optimizer to use clever inlining, use SSE etc where it makes sense
Am 31.07.2014 17:26, schrieb Artur Skawina via Digitalmars-d:
On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get why anyone would want such an optimization: I want an
On 7/31/14, 12:13 AM, Kagamin wrote:
On Wednesday, 30 July 2014 at 20:41:15 UTC, Andrei Alexandrescu wrote:
Yah but then we have stuttering such as log.log(ehm) which is oddly
the same as log(ehm).
log.write
log.writef
Then you have the globals write and writef which will compete with those
On Thursday, 31 July 2014 at 07:42:16 UTC, Walter Bright wrote:
On 7/30/2014 6:16 PM, Dicebot wrote:
On Wednesday, 30 July 2014 at 23:50:51 UTC, H. S. Teoh via
Digitalmars-d wrote:
But if you don't want to check ever to be removed, currently
you have to
write:
if (!requiredCondition)
On Thursday, 31 July 2014 at 15:37:23 UTC, Daniel Gibson wrote:
If removing code makes my code faster, I can do it myself.
No, in general you can't. Opportunities for dead code elimination
often only present themselves after inlining and/or in generic
(as in templates) code.
David
Daniel Gibson:
asm { : : m
(*cast(typeof(password[0])[999]*)password.ptr); }
inline asm is not portable
See:
https://d.puremagic.com/issues/show_bug.cgi?id=10661
C11 defines a memset_s which is guaranteed not to be optimized
away..
that's 9 years after that bugreport and will
Justin Whear:
In addition to the suggestions of Algebraic or Variant
elsewhere in this
thread, it's trivial to implement your own concrete tagged
unions:
struct MyTaggedUnion
{
enum Type { Int, Float, String }
Type tag;
union {
int int_;
float float_;
string
On 07/31/14 17:37, Daniel Gibson via Digitalmars-d wrote:
Am 31.07.2014 17:26, schrieb Artur Skawina via Digitalmars-d:
On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get why
On 7/31/14, 6:03 AM, w0rp wrote:
On Thursday, 31 July 2014 at 11:42:21 UTC, Remo wrote:
http://tech.esper.com/2014/07/30/algebraic-data-types/
D already has product type it is struct.
But D lacks sum type also called tagged-union.
Do you think it would be possible to add something like this
On 7/31/14, 8:37 AM, Daniel Gibson wrote:
When I tell it to write something, I want it to do that, even if it
might look like nonsense (if anything, it could create a warning).
I'm afraid those days are long gone by now. -- Andrei
On Thu, Jul 31, 2014 at 03:44:35PM +0200, Daniel Gibson via Digitalmars-d wrote:
[...]
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get why anyone would want such an optimization: I want
an optimizer to use clever inlining, use SSE
On Thursday, 31 July 2014 at 15:37:23 UTC, Daniel Gibson wrote:
Am 31.07.2014 17:26, schrieb Artur Skawina via Digitalmars-d:
On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get
On Thursday, 31 July 2014 at 10:14:06 UTC, Marc Schütz wrote:
On Thursday, 31 July 2014 at 08:23:44 UTC, Daniel Murphy wrote:
Daniel Murphy wrote in message
news:lrct2d$1me8$1...@digitalmars.com...
Wait, what? I thought the whole point of enforce is that it
will *not*
be removed by the
On Thursday, 31 July 2014 at 16:37:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 31, 2014 at 03:44:35PM +0200, Daniel Gibson via
Digitalmars-d wrote:
[...]
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get why anyone would
On Thu, Jul 31, 2014 at 02:05:29AM +, Tofu Ninja via Digitalmars-d wrote:
On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright wrote:
3. Use of assert to validate input is utterly wrong and will not be
supported. Use such constructs at your own risk.
When exactly is it 'ok' to use
On Thursday, 31 July 2014 at 15:26:27 UTC, Artur Skawina via
Digitalmars-d wrote:
On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
And don't forget this (rather old) case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
(I really don't get why anyone would want such an
optimization:
Daniel Gibson wrote in message news:lrdnri$2fge$1...@digitalmars.com...
One could write a memset_s oneself.. that does a memset, reads the data
and writes a char of it or something to a global variable (hoping that the
compiler won't optimize that to just set that variable to 0).
Some
On Thursday, 31 July 2014 at 17:10:27 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 31, 2014 at 02:05:29AM +, Tofu Ninja via
Digitalmars-d wrote:
On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright
wrote:
3. Use of assert to validate input is utterly wrong and will
not be
On Wed, Jul 30, 2014 at 06:07:57PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
A coworker asked about the idiomatic way to get the hash of a string
in D, and somewhat surprisingly the best answer I could find is: to
get the hash of an lvalue x, call typeof(x).getHash(x).
That's
Am 31.07.2014 18:29, schrieb Andrei Alexandrescu:
On 7/31/14, 8:37 AM, Daniel Gibson wrote:
When I tell it to write something, I want it to do that, even if it
might look like nonsense (if anything, it could create a warning).
I'm afraid those days are long gone by now. -- Andrei
At least
On Thursday, 31 July 2014 at 17:40:45 UTC, Daniel Gibson wrote:
Am 31.07.2014 18:29, schrieb Andrei Alexandrescu:
On 7/31/14, 8:37 AM, Daniel Gibson wrote:
When I tell it to write something, I want it to do that, even
if it
might look like nonsense (if anything, it could create a
warning).
Tofu Ninja wrote in message news:mhhtxjlrvtqhzztxi...@forum.dlang.org...
With that logic(and the proposed optimizations that this whole thing is
about), weird stuff like this happens...
void foo(int x)
{
if(x != 0) throw ...;
assert(x == 0);
}
The if check could be removed because
Hi,
consider this code:
import std.stdio;
import std.concurrency;
import core.thread;
void tryOpen()
{
Thread.sleep(2.seconds);
try {
auto f = File(nonexistent);
}
catch (Exception e) {
writeln(Could not open a file);
}
}
void main()
{
spawn(tryOpen);
readln();
}
On
Note that output to stdout is not good choice to check event
order, because it's buffered. Try to flush stdout or write to
stderr. Maybe it's actual problem.
On 7/31/14, 4:37 AM, Walter Bright wrote:
On 7/30/2014 4:05 PM, Ary Borenszweig wrote:
On 7/30/14, 7:01 PM, Walter Bright wrote:
I'd like to sum up my position and intent on all this.
7. using enforce() to check for program bugs is utterly wrong. enforce()
is a library creation, the core
On 7/31/2014 4:28 AM, David Bregman wrote:
Sigh. Of course you can assume the condition after a runtime check has been
inserted. You just showed that
assert(x); assume(x);
is semantically equivalent to
assert(x);
as long as the runtime check is not elided. (no -release)
No. I showed that
On 7/31/2014 3:24 AM, ponce wrote:
On Thursday, 31 July 2014 at 09:13:53 UTC, Walter Bright wrote:
On 7/31/2014 1:23 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:lrbpvj$mih$1...@digitalmars.com...
5. assert(0); is equivalent to a halt, and the compiler won't remove it.
On Thursday, 31 July 2014 at 17:39:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
It's about time somebody noticed this!!
Why don't we just expose druntime's core.internal.hash.hashOf()
function
somewhere? It's not as though it isn't already in druntime, so
the
function is already present in the
On 31.7.2014 20:37, FreeSlave via Digitalmars-d wrote:
Note that output to stdout is not good choice to check event order,
because it's buffered. Try to flush stdout or write to stderr. Maybe
it's actual problem.
Hi,
this is just for illustration, although I think that writeln flushes
itself.
On 7/31/2014 7:51 AM, Tofu Ninja wrote:
For example, you can have a sort function, and then at the end assert that the
output of the function is sorted.
But that is verifying that the input is sort-able
Integers are sortable, period. That is not input.
All I am saying is that the idea
On 07/31/2014 09:03 PM, Walter Bright wrote:
On 7/31/2014 3:24 AM, ponce wrote:
On Thursday, 31 July 2014 at 09:13:53 UTC, Walter Bright wrote:
On 7/31/2014 1:23 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:lrbpvj$mih$1...@digitalmars.com...
5. assert(0); is equivalent to a
On 7/31/2014 6:37 AM, Daniel Gibson wrote:
The behavior you desire here is easily handled by creating your own
template to exhibit it. See the implementation of enforce() for how to
do it.
Now that's a bit surprising to me, as you wrote in the other thread:
7. using enforce() to check for
1 - 100 of 252 matches
Mail list logo
