On Thursday, 23 April 2015 at 01:45:14 UTC, deadalnix wrote:
On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and elide them and
On Wednesday, 22 April 2015 at 10:36:04 UTC, Jonathan M Davis
wrote:
> So, the obvious thing for a C programmer when they see
>
> if(arr)
>
> would be to think that it was equivalent to
>
> if(arr != NULL)
Don't you contradict yourself now?
arr!=null is equivalent to arr.length!=0
that I meant
> On Wednesday, 22 April 2015 at 20:29:49 UTC, Walter Bright wrote:
>>
>> On 4/22/2015 12:51 PM, ponce wrote:
>>>
>>> I didn't appreciate how important default initialization was before
>>> having to
>>> fix a non-deterministic, release-only, time-dependent bug in a video
>>> encoder
>>> some month
On 23 April 2015 at 00:23, Martin Nowak via Digitalmars-d
wrote:
> On 04/22/2015 01:36 PM, Dicebot wrote:
>>
>> -d is your enemy, If you remove that, there will be a clear warning
>> "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer
>> should be static, __gshared, or an enum".
On Wednesday, 22 April 2015 at 22:23:30 UTC, Martin Nowak wrote:
On 04/22/2015 01:36 PM, Dicebot wrote:
-d is your enemy, If you remove that, there will be a clear
warning
"Deprecation: variable XXX.S.FLAG_ON immutable field with
initializer
should be static, __gshared, or an enum". You decid
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size stack-allocated
associative arrays. In D you can't even allocate safely a
dynamically-sized 1D array on the stack, and forg
Why can no compiler I try optimise this toy example as I would
expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a < 5)
return (a * 3) / 3;
else
return 0;
}
So, I would expect the compiler to be able to see that it is
equivalent to
ui
On Thursday, 23 April 2015 at 08:33:56 UTC, John Colvin wrote:
Why can no compiler I try optimise this toy example as I would
expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a < 5)
return (a * 3) / 3;
else
return 0;
}
So, I would expe
On Wednesday, 22 April 2015 at 19:37:21 UTC, Steven Schveighoffer
wrote:
Yeah, I like this. But now we have to name the flag :)
I don't think it should be a bool, because:
isInputRange!(R, true)
Is pretty obtuse. I'd rather see something like:
isInputRange!(R, RangeOption.NonCopyable)
Or wha
On Thursday, 23 April 2015 at 08:56:38 UTC, rumbu wrote:
On Thursday, 23 April 2015 at 08:33:56 UTC, John Colvin wrote:
Why can no compiler I try optimise this toy example as I would
expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a < 5)
retu
On Thursday, 23 April 2015 at 08:11:50 UTC, Daniel Kozak wrote:
On Wednesday, 22 April 2015 at 22:23:30 UTC, Martin Nowak wrote:
On 04/22/2015 01:36 PM, Dicebot wrote:
-d is your enemy, If you remove that, there will be a clear
warning
"Deprecation: variable XXX.S.FLAG_ON immutable field with
On Thursday, 23 April 2015 at 08:33:56 UTC, John Colvin wrote:
Why can no compiler I try optimise this toy example as I would
expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a < 5)
return (a * 3) / 3;
else
return 0;
}
So, I would expe
On 23/04/2015 10:02 p.m., Andrea Fontana wrote:
On Thursday, 23 April 2015 at 08:33:56 UTC, John Colvin wrote:
Why can no compiler I try optimise this toy example as I would expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a < 5)
return (a *
On Thursday, 23 April 2015 at 10:04:47 UTC, Rikki Cattermole
wrote:
On 23/04/2015 10:02 p.m., Andrea Fontana wrote:
On Thursday, 23 April 2015 at 08:33:56 UTC, John Colvin wrote:
Why can no compiler I try optimise this toy example as I
would expect?
// uncomment if using a C compiler
// typed
On Wednesday, 22 April 2015 at 16:10:37 UTC, Steven Schveighoffer
wrote:
You are misunderstanding what deprecation means then. The whole
point is "the semantics are going to change, please update your
code, it's coming soon". The -d is a way to get your code to
compile now while you update.
S
On Thursday, 23 April 2015 at 10:08:24 UTC, John Colvin wrote:
asm.dlang.org
and d.godbolt.org
This isn't a D-specific question though, so gcc.godbolt.org
would allow you to test a wider range of backends.
I was wondering if compilers can optimize this:
uint foo3(uint a)
{
return a*!(a/5
On Thursday, 23 April 2015 at 08:33:56 UTC, John Colvin wrote:
Why can no compiler I try optimise this toy example as I would
expect?
// uncomment if using a C compiler
// typedef unsigned int uint;
uint foo(uint a)
{
if (a < 5)
return (a * 3) / 3;
else
return 0;
}
It is interesti
On 4/22/15 6:10 PM, Martin Nowak wrote:
Interesting trivia, I even found this bug in the documentation of the
first dmd release http://downloads.dlang.org/releases/0.x/0.100/dmd.100.zip.
Checking For Empty Strings
C++ strings use a function to determine if a string is empty:
string str
On Thursday, 23 April 2015 at 08:56:38 UTC, rumbu wrote:
I think because of the potential overflow in a * 3 (if we
ignore the a < 5 condition). To optimize this, a compiler must
figure out that there is no overflow for any a < 5.
Yes, it is because of modular artithmetics which is a D design
On Wednesday, 22 April 2015 at 10:36:04 UTC, Jonathan M Davis
wrote:
D arrays were designed in a way that they avoid segfaults;
otherwise an
empty array and a null array would not be considered equal, and
doing stuff
like trying to append to a null array would segfault. You have
to work at it
t
On Thursday, 23 April 2015 at 12:37:12 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 April 2015 at 08:56:38 UTC, rumbu wrote:
I think because of the potential overflow in a * 3 (if we
ignore the a < 5 condition). To optimize this, a compiler must
figure out that there is no overflow for any a
Interestingly only clang understands that an upcast will prevent
the overflow:
int foo(unsigned int a)
{
if (a > 5)
return ((unsigned long long)a * 3) / 3;
else
return 0;
}
Is compiled to compact code in clang:
xorl%eax, %eax
On 4/23/15 5:03 AM, Dominikus Dittes Scherkl wrote:
On Wednesday, 22 April 2015 at 19:37:21 UTC, Steven Schveighoffer wrote:
Yeah, I like this. But now we have to name the flag :)
I don't think it should be a bool, because:
isInputRange!(R, true)
Is pretty obtuse. I'd rather see something lik
On 4/23/15 6:14 AM, Kagamin wrote:
On Wednesday, 22 April 2015 at 16:10:37 UTC, Steven Schveighoffer wrote:
You are misunderstanding what deprecation means then. The whole point
is "the semantics are going to change, please update your code, it's
coming soon". The -d is a way to get your code to
We can make it an error in 2.067.1 and change semantics in 2.067
- actually I'd recommend to do it that way. Breaking normal
deprecation process is not good.
On 4/23/15 9:09 AM, Dicebot wrote:
We can make it an error in 2.067.1 and change semantics in 2.067 -
actually I'd recommend to do it that way. Breaking normal deprecation
process is not good.
I agree it should have been done, not saying it's OK to break the
process in some cases. I'm just exp
On Wednesday, 22 April 2015 at 22:26:45 UTC, John Colvin wrote:
On Wednesday, 22 April 2015 at 21:59:48 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technical
So, I was tooling around with one of the benchmarks I saw listed
on twitter:
https://github.com/kostya/benchmarks/tree/master/brainfuck
This D benchmark spends most of it's time on AA lookups.
Discussions about the implementation aside, I am curious as to
why the D AA is so slow even after
On Thursday, 23 April 2015 at 14:29:01 UTC, Ola Fosheim Grøstad
wrote:
Can you give a specific example where all 3 points are
satisfied?
Not sure why you would need it, plenty of cases where compilers
will fail. E.g. queues between threads (like real time threads)
where you allocate in one th
On 23 April 2015 at 16:28, via Digitalmars-d
wrote:
> On Wednesday, 22 April 2015 at 22:26:45 UTC, John Colvin wrote:
>>
>> On Wednesday, 22 April 2015 at 21:59:48 UTC, Ola Fosheim Grøstad wrote:
>>>
>>> On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even possible
On Thursday, 23 April 2015 at 14:55:42 UTC, Iain Buclaw wrote:
There are two states each local variable can be assigned.
1. Used
2. Read
int a = 1; // a = Used
return a; // a = Read
printf("%d\n", a); // a = Read
int b = a; // b = Used, a = Read
int c = void; // c = Unused
If a variable is
On Thursday, 23 April 2015 at 14:50:26 UTC, John Colvin wrote:
There are cases where you might really need to grab an extra
1-5%, at which point you are hand optimising and = void is a
reasonable tool.
Well, it can be a lot more than 1-5% in special situations if you
hand over a small header
On 4/23/15 10:40 AM, Shammah Chancellor wrote:
2) I saw a thread awhile ago where someone had posted an updated
implementation of the AA with benchmarks and showed that it was
substantially faster in all cases. I can't find the thread again --
what happened with this work?
There is a PR being
Dub provides an easy way to utilizes 3rd party libraries, github
provides an easy way to revive a project no longer being
maintained by the author. Can we come up with a solution within
code.dlang to take advantage of this?
While I'd prefer if the project owner would proved commit rights
to t
On 4/23/15 11:43 AM, Jesse Phillips wrote:
Dub provides an easy way to utilizes 3rd party libraries, github
provides an easy way to revive a project no longer being maintained by
the author. Can we come up with a solution within code.dlang to take
advantage of this?
While I'd prefer if the proje
Reminder about tonight's meetup:
http://www.meetup.com/D-Lang-Silicon-Valley/events/221371799/
Apcera
585 Howard Street (Third Floor), San Francisco, CA (edit map)
Food, beverages, and venue are provided by Apcera
(http://www.apcera.com)
We are having a lightning talk meeting this month:
Ali
"John Colvin" writes:
> On Wednesday, 22 April 2015 at 16:27:59 UTC, Wyatt wrote:
>> On Wednesday, 22 April 2015 at 15:44:03 UTC, Dan Olson wrote:
>>>
>>> Super and Hyper keys
>>>
>> A veteran of the Lisp machines! I've been hoping for someone to
>> manufacture a modern keyboard with these for a
Wikipedia article and why default emacs key bindings are painful today.
http://en.wikipedia.org/wiki/Space-cadet_keyboard
http://ergoemacs.org/emacs/emacs_kb_shortcuts_pain.html
Iain Buclaw via Digitalmars-d writes:
>
> (FYI - last time I checked GDC goes ahead and applied target-specific
> mangling on-top of pragma(mangle). So you can relax and assume
> nothing about the target).
So does LDC.
Actually, DMD does too on OS X, but only for extern(C) - attention to
func p
Iain Buclaw via Digitalmars-d writes:
>
> Because of this, debugging in OSX is not as good as it could be (if
> you use DMD). All debuggers I've seen remove the leading '_' from
> symbols before they begin demangling symbols.
And I noticed __cxa_demangle() is defined that way. Target specific
pr
On Thursday, 23 April 2015 at 06:32:39 UTC, Jacob Carlborg wrote:
On 2015-04-23 04:00, deadalnix wrote:
D style hello world is HUGE. writeln need half of the world to
work to
spit out anything :)
What about "Hello World" with "printf" instead?
We can do this already :)
Yes, It is also ne
On Thursday, 23 April 2015 at 16:00:31 UTC, Steven Schveighoffer
wrote:
Not perfect, but I don't think there really is anything we can
do about no-longer-maintained projects. It's not fair to the
author that they can have their project taken over and
published with their name. At least we can h
On 23 April 2015 at 19:15, Dan Olson via Digitalmars-d
wrote:
> Iain Buclaw via Digitalmars-d writes:
>>
>> (FYI - last time I checked GDC goes ahead and applied target-specific
>> mangling on-top of pragma(mangle). So you can relax and assume
>> nothing about the target).
>
> So does LDC.
>
> A
On Saturday, 18 April 2015 at 15:24:27 UTC, w0rp wrote:
The following code almost compiles.
import core.stdc.stdlib;
class Foo : Exception {
@nogc pure nothrow @safe
this(string msg, string file = __FILE__, size_t line =
__LINE__, Throwable next = null) {
super(msg, f
On 4/23/2015 1:10 AM, bearophile wrote:
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size stack-allocated associative
arrays. In D you can't even allocate safely a dynamicall
On Thursday, 23 April 2015 at 18:07:48 UTC, Iain Buclaw wrote:
A 'nice to know' which is specific to GDC. If you prefix
pragma(mangle) names with "*" then it will not apply
target-dependent
prefixes.
For LLVM, this works by prefixing the name with \1.
We need to do this internally for naked
On 4/23/15 1:57 PM, Jesse Phillips wrote:
On Thursday, 23 April 2015 at 16:00:31 UTC, Steven Schveighoffer wrote:
Not perfect, but I don't think there really is anything we can do
about no-longer-maintained projects. It's not fair to the author that
they can have their project taken over and pub
void main(string[] args)
{
int a = 1;
int b = to!int(args[1]);
uint c = 2;
switch (a)
{
case b: break; // OK
case c: break; // Error: variable c cannot be read at
compile time
default: break;
}
}
Switch spec says:
The case expressions must all e
On 4/23/15 4:25 PM, bearophile wrote:
Martin Krejcirik:
So, should the case b compile or not ? Is the spec too restrictive
here, or is it a bug ?
Apparently it's a WONTFIX mess. The spec should be updated.
Walter&Andrei refused to fix a design bug here.
Source?
IMO, the OP code does not wa
Martin Krejcirik:
So, should the case b compile or not ? Is the spec too
restrictive here, or is it a bug ?
Apparently it's a WONTFIX mess. The spec should be updated.
Walter&Andrei refused to fix a design bug here.
Bye,
bearophile
On Thursday, 23 April 2015 at 18:37:47 UTC, Walter Bright wrote:
On 4/23/2015 1:10 AM, bearophile wrote:
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size
stack-allocated a
On Thursday, April 23, 2015 16:29:03 Steven Schveighoffer via Digitalmars-d
wrote:
> On 4/23/15 4:25 PM, bearophile wrote:
> > Martin Krejcirik:
> >
> >> So, should the case b compile or not ? Is the spec too restrictive
> >> here, or is it a bug ?
> >
> > Apparently it's a WONTFIX mess. The spec
On 4/23/15 5:04 PM, Jonathan M Davis via Digitalmars-d wrote:
On Thursday, April 23, 2015 16:29:03 Steven Schveighoffer via Digitalmars-d
wrote:
On 4/23/15 4:25 PM, bearophile wrote:
Martin Krejcirik:
So, should the case b compile or not ? Is the spec too restrictive
here, or is it a bug ?
On Thursday, 23 April 2015 at 18:37:47 UTC, Walter Bright wrote:
On 4/23/2015 1:10 AM, bearophile wrote:
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size
stack-allocated a
On Thursday, 23 April 2015 at 20:40:36 UTC, John Colvin wrote:
scopeBuffer), but in practice it's not a big win over just
stack allocating the maximum size all the time (again, like
scopeBuffer).
If you have a random distribution of sizes then allocating the
maximum will use twice as much mem
On Thursday, 23 April 2015 at 18:37:47 UTC, Walter Bright wrote:
On 4/23/2015 1:10 AM, bearophile wrote:
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size
stack-allocated a
https://github.com/D-Programming-Language/dmd/pull/2887
Ugh...
at the VERY LEAST, the error message should be fixed, as "can't
be read at compile time" is clearly not the issue.
Looks like this issue surfaces periodically. Somehow I've missed
it so far.
Anyway, either the spec is wrong or t
On 4/23/2015 2:54 PM, weaselcat wrote:
Is there a reason scopebuffer isn't part of the documentation?
Everyone hated it :-) but me.
On 4/23/2015 3:11 PM, deadalnix wrote:
For arbitrary large, you can always do something like :
Item* itemPtr = (arbitrarylarge < thresold)
? alloca(arbitrarylarge)
: GC.alloc(arbitrarylarge);
One extra check compared to a heap allocation is not going to make things
terrible, and it is lik
On 4/23/2015 1:33 AM, John Colvin wrote:
Is there a good reason for this,
Modern compilers check for literally thousands of such patterns, and more are
constantly added. There's an infinitely "long tail" of these patterns possible,
and at some point, you have to ship the compiler.
The ones
On 4/23/2015 5:37 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
Yes, it is because of modular artithmetics which is a D design flaw.
Out of the innumerable posts you write, I can't recall one which didn't assert
that whatever D does is wrong.
On 4/23/2015 6:26 AM, Steven Schveighoffer wrote:
On 4/23/15 9:09 AM, Dicebot wrote:
We can make it an error in 2.067.1 and change semantics in 2.067 -
actually I'd recommend to do it that way. Breaking normal deprecation
process is not good.
I agree it should have been done, not saying it's O
On 4/23/2015 3:23 AM, Andrea Fontana wrote:
I was wondering if compilers can optimize this:
uint foo3(uint a)
{
return a*!(a/5);
}
That actually gives the same results.
A fun article about these sorts of things:
http://www.davespace.co.uk/blog/20150131-branchless-sequences.html
On Thu, 23 Apr 2015 19:05:06 -0700, Walter Bright wrote:
> On 4/23/2015 5:37 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
> " wrote:
>> Yes, it is because of modular artithmetics which is a D design flaw.
>
> Out of the innumerable posts you write, I can't recall one which didn't
> assert that whate
On 4/23/2015 10:57 AM, Jesse Phillips wrote:
Github already allows this, it also makes sure modifications are correctly
authored (at least with the author specified in the commit, which can easily be
faked). It think it is completely fair, the author published their source for
others to use and m
On Thursday, 23 April 2015 at 10:23:57 UTC, Andrea Fontana wrote:
On Thursday, 23 April 2015 at 10:08:24 UTC, John Colvin wrote:
asm.dlang.org
and d.godbolt.org
This isn't a D-specific question though, so gcc.godbolt.org
would allow you to test a wider range of backends.
I was wondering if
66 matches
Mail list logo
