On Fri, 13 Jun 2014 03:33:40 +
Khaled via Digitalmars-d wrote:
> Hi,
>
> Since I become a D fan, I decided to come up with a logo designs
> for this awesome language. If you like one of these designs and
> require some modifications then send me your feedbacks so I can
> update it accordingly
On Saturday, 14 June 2014 at 02:30:56 UTC, Chris Cain wrote:
On Saturday, 14 June 2014 at 02:12:45 UTC, Jeremy DeHaan wrote:
I agree. Also, this page (http://dlang.org/dmd-osx.html) says
that the base requirement is a 32 bit OSX. Why is the DMD
version that is released 64 bit? That seems very c
On Saturday, 14 June 2014 at 02:12:45 UTC, Jeremy DeHaan wrote:
I agree. Also, this page (http://dlang.org/dmd-osx.html) says
that the base requirement is a 32 bit OSX. Why is the DMD
version that is released 64 bit? That seems very counter
intuitive.
Honestly, I feel like it should be noted
On Friday, 13 June 2014 at 15:14:00 UTC, Tolga Cakiroglu wrote:
On Friday, 13 June 2014 at 07:13:36 UTC, Jacob Carlborg wrote:
On 13/06/14 07:26, Tolga Cakiroglu wrote:
In the download page, table shows for which CPU type they are
available.
dmd.2.065.0.zip shows i386 and x86_64. So, this sho
On Thursday, 12 June 2014 at 14:23:59 UTC, Jacob Carlborg wrote:
On 12/06/14 11:48, Kagamin wrote:
Why private members can't have internal linkage?
It's currently possible to access private symbols through
pointers.
You don't need a symbol in the object file for that.
On Thursday, 12 June 2014 at 14:48:41 UTC, Dicebot wrote:
On Thursday, 12 June 2014 at 14:23:59 UTC, Jacob Carlborg wrote:
On 12/06/14 11:48, Kagamin wrote:
Why private members can't have internal linkage?
It's currently possible to access private symbols through
pointers.
And aliases with
On Friday, 13 June 2014 at 09:41:36 UTC, Guillaume Chatelet wrote:
I like them !
Do you want to create a doodle or a form so people can vote ?
I think it would a good idea to create a form so people can
select one logo among those seven designs. And by that, I would
be able to apply required
On Saturday, 14 June 2014 at 00:40:06 UTC, Jonathan M Davis via
Digitalmars-d wrote:
True, some types become problematic when you have to have an
init value (like
a NonNullable struct to make nullable pointers non-nullable),
but generic code
is way more of a pain to write when you can't rely on
On Sat, 14 Jun 2014 00:34:51 +0200
Timon Gehr via Digitalmars-d wrote:
> On 06/13/2014 11:45 PM, Jonathan M Davis via Digitalmars-d wrote:
> > On Fri, 13 Jun 2014 21:23:00 +
> > deadalnix via Digitalmars-d wrote:
> >
> >> The approach consisting in having non nullable pointers/reference
> >>
On Friday, 13 June 2014 at 03:33:41 UTC, Khaled wrote:
https://drive.google.com/file/d/0B_LJS0oMStiPVzJvRzBhTC1EaXc/edit?usp=sharing
Overall, I like them. I agree that it's not intuitive that it's a
"d", but I don't think that's a strong drawback, if all you want
is something cool to put on a
On Fri, Jun 13, 2014 at 10:34:09PM +, via Digitalmars-d wrote:
[...]
> On Friday, 13 June 2014 at 22:21:15 UTC, Meta wrote:
> >It's a joke, though I suppose not a very good one. If 1 == 1 doesn't
> >indicate a condition that should never be false to you, then you're
> >bad at math.
>
> Imagine
On Fri, Jun 13, 2014 at 10:15:59PM +, monarch_dodra via Digitalmars-d wrote:
> On Friday, 13 June 2014 at 22:07:53 UTC, H. S. Teoh via Digitalmars-d wrote:
> >>The very idea of a loop without a condition seems very, very wrong
> >>to me.
> >
> >Why would it be "very, very wrong"? Perpetual cycl
On Friday, 13 June 2014 at 21:41:43 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The very idea of a loop without a condition seems very, very
wrong to me.
I like Rust's "loop". :3 I'm not sure of the exact stats, but a
ton of my non-D loops are infinite, with or without breaks, like
with lo
On 06/13/2014 11:45 PM, Jonathan M Davis via Digitalmars-d wrote:
On Fri, 13 Jun 2014 21:23:00 +
deadalnix via Digitalmars-d wrote:
The approach consisting in having non nullable pointers/reference
by default is the one that is gaining traction and for good
reasons.
That interacts _reall
On Friday, 13 June 2014 at 21:12:20 UTC, Timon Gehr wrote:
Why do you claim he is bad at math?
It's a joke, though I suppose not a very good one. If 1 == 1
doesn't indicate a condition that should never be false to you,
then you're bad at math.
On Friday, 13 June 2014 at 22:07:53 UTC, H. S. Teoh via
Digitalmars-d wrote:
The very idea of a loop without a condition seems very, very
wrong to
me.
Why would it be "very, very wrong"? Perpetual cycles are
ubiquitous in
nature
Hum... you guys seem to be forgetting about break statements.
On Fri, Jun 13, 2014 at 11:41:34PM +0200, Jonathan M Davis via Digitalmars-d
wrote:
> On Fri, 13 Jun 2014 11:03:14 -0700
> "H. S. Teoh via Digitalmars-d" wrote:
>
> > On Fri, Jun 13, 2014 at 10:46:17AM -0700, Jonathan M Davis via
> > Digitalmars-d wrote: [...]
> > > for(;;) is a special case wit
On Fri, 13 Jun 2014 21:23:00 +
deadalnix via Digitalmars-d wrote:
> The approach consisting in having non nullable pointers/reference
> by default is the one that is gaining traction and for good
> reasons.
That interacts _really_ badly with D's approach of requiring init values for
all type
On Fri, 13 Jun 2014 11:03:14 -0700
"H. S. Teoh via Digitalmars-d" wrote:
> On Fri, Jun 13, 2014 at 10:46:17AM -0700, Jonathan M Davis via
> Digitalmars-d wrote: [...]
> > for(;;) is a special case with no real benefit IMHO. It's a loop whose
> > condition is implicitly true rather than actually h
This indeed has been already discussed. Long story short :
Making dereferencing null a defined behavior is extremely
expensive from the optimizer perspective. That mean that every
single load can have side effect, so the optimizer can't optimize
them away unless it can prove that the pointer is n
On 2014-06-13 16:39:04 +, H. S. Teoh via Digitalmars-d said:
Basically, once the derived class overrides the property setter, the
(un-overridden) base class getter somehow becomes shadowed as well, and
references to .prop will cause a compile error saying that Derived.prop
can't be called w
On 2014-06-13 03:33:40 +, Khaled said:
Hi,
Since I become a D fan, I decided to come up with a logo designs for
this awesome language. If you like one of these designs and require
some modifications then send me your feedbacks so I can update it
accordingly.
https://drive.google.com/fi
On 06/13/2014 07:39 PM, Meta wrote:
On Friday, 13 June 2014 at 17:05:26 UTC, H. S. Teoh via Digitalmars-d
wrote:
I don't like arbitrary constants like the `true` in while(true) -- it
kinda goes against the grain, that "while" implies there is a stopping
point, but sticking true in there contradi
This was surely discussed in past, but I don't remember the
answer (so perhaps this is more fit in D.learn).
Dereferencing the null pointer in C is undefined behaviour, so in
most cases the program segfaults, but sometimes the compiler
assumes a dereferenced pointer can't be null, so it optimi
On Fri, 13 Jun 2014 01:27:24 -0400, Manu via Digitalmars-d
wrote:
On 13 June 2014 14:14, Steven Schveighoffer via Digitalmars-d
wrote:
Some forward ranges don't have a known length, and can only be summed
by an iteration sweep.
http://dlang.org/phobos/std_range.html#.walkLength
That's
On Fri, 13 Jun 2014 13:03:50 -0400, H. S. Teoh via Digitalmars-d
wrote:
On Fri, Jun 13, 2014 at 12:54:44PM -0400, Nick Sabalausky via
Digitalmars-d wrote:
On 6/13/2014 5:15 AM, Jonathan M Davis via Digitalmars-d wrote:
>
>I'd honestly rather see for(;;) {} removed than have foreach(; 0..n)
On Friday, 13 June 2014 at 18:18:21 UTC, H. S. Teoh via
Digitalmars-d wrote:
Aliasing super.prop to .prop in the derived class didn't work,
in fact,
it made things worse; now I have an infinite loop because all
occurrences of .prop get redirected back to the base class
(including
the setter), a
On Friday, 13 June 2014 at 15:14:00 UTC, Tolga Cakiroglu wrote:
On Friday, 13 June 2014 at 07:13:36 UTC, Jacob Carlborg wrote:
On 13/06/14 07:26, Tolga Cakiroglu wrote:
In the download page, table shows for which CPU type they are
available.
dmd.2.065.0.zip shows i386 and x86_64. So, this sho
Odd, I thought you weren't able to override only a single
overload of a property? I might be imagining things, but I recall
at least previously that you had to override all getters/setters
if you wanted to override any for a property.
Personally I think D made a significant mistake in the way
On Fri, Jun 13, 2014 at 10:53:38AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Fri, 13 Jun 2014 09:39:04 -0700
> "H. S. Teoh via Digitalmars-d" wrote:
>
> > I'm not sure if this is a bug, or an anti-pattern, or what, but I ran
> > into this issue yesterday:
> >
> > class Base {
> >
On Fri, Jun 13, 2014 at 10:46:17AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]
> for(;;) is a special case with no real benefit IMHO. It's a loop whose
> condition is implicitly true rather than actually having a condition
> in it. IMHO, it should required to be at least for(;1;) or
>
On Fri, 13 Jun 2014 09:39:04 -0700
"H. S. Teoh via Digitalmars-d" wrote:
> I'm not sure if this is a bug, or an anti-pattern, or what, but I ran
> into this issue yesterday:
>
> class Base {
> int propImpl;
> final @property int prop() { return propImpl; }
> @property void pro
On Fri, 13 Jun 2014 14:25:19 +
monarch_dodra via Digitalmars-d wrote:
> On Friday, 13 June 2014 at 09:29:25 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
> > I'd honestly rather see for(;;) {} removed than have foreach(;
> > 0..n) {} added.
>
> Just out of curiosity, what is it you don't l
On Friday, 13 June 2014 at 17:05:26 UTC, H. S. Teoh via
Digitalmars-d wrote:
I don't like arbitrary constants like the `true` in while(true)
-- it kinda goes against the grain, that "while" implies there
is a stopping point, but sticking true in there contradicts
this notion and is
therefore d
On Fri, Jun 13, 2014 at 12:54:44PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
> On 6/13/2014 5:15 AM, Jonathan M Davis via Digitalmars-d wrote:
> >
> >I'd honestly rather see for(;;) {} removed than have foreach(; 0..n)
> >{} added. I don't like special cases like like these.
> >
>
> Disall
On 6/13/2014 5:15 AM, Jonathan M Davis via Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed than have foreach(; 0..n) {} added.
I don't like special cases like like these.
Disallowing for(;;) would *be* a special case. Each of the three parts
can be individually omitted, and t
I'm not sure if this is a bug, or an anti-pattern, or what, but I ran
into this issue yesterday:
class Base {
int propImpl;
final @property int prop() { return propImpl; }
@property void prop(int newVal) { propImpl = newVal; }
On Friday, 13 June 2014 at 15:48:37 UTC, Timon Gehr wrote:
On 06/13/2014 01:55 PM, Dicebot wrote:
Over 50 comments about minor syntax issue ...
Including yours.
That was my first comment in this thread :O
On Thursday, 12 June 2014 at 22:38:26 UTC, Daniel Kozák via
Digitalmars-d wrote:
No problem for me:
http://stackoverflow.com/questions/23950796/how-to-repeat-a-statement-n-times-simple-loop/23952012#23952012
Now put a break statement in the loop body.
On 06/13/2014 01:55 PM, Dicebot wrote:
Over 50 comments about minor syntax issue ...
Including yours.
Am 13.06.2014 16:59, schrieb Dejan Lekic:
Please no. See: javax
Spelling out 'experimental' is probably the best, for all those
reasons
already stated.
What's wrong with javax?
experimental is 100% clear and simple to understand beeing evil
javax was interpreted as eXtendet or eXtra or wh
On Friday, 13 June 2014 at 15:18:52 UTC, Nick Treleaven wrote:
On 12/06/2014 16:57, simendsjo wrote:
Does any sane person use _ as a variable identifier and
then reference it?
I forgot that C gettext has a macro called _(), and this D
version also has it (which is available via dub):
https:
On 12/06/2014 16:57, simendsjo wrote:
Does any sane person use _ as a variable identifier and
then reference it?
I forgot that C gettext has a macro called _(), and this D version also
has it (which is available via dub):
https://github.com/NCrashed/dtext/blob/master/source/dtext.d#L115
str
On Friday, 13 June 2014 at 07:13:36 UTC, Jacob Carlborg wrote:
On 13/06/14 07:26, Tolga Cakiroglu wrote:
In the download page, table shows for which CPU type they are
available.
dmd.2.065.0.zip shows i386 and x86_64. So, this should run on
32 and
64-bits.
dmd.2.065.0.dmg shows only x86_64 wh
On Friday, 13 June 2014 at 14:59:55 UTC, Dejan Lekic wrote:
Please no. See: javax
Spelling out 'experimental' is probably the best, for all
those reasons
already stated.
What's wrong with javax?
The fact that it started as same experimental package but stuff
there never got moved to main
Please no. See: javax
Spelling out 'experimental' is probably the best, for all those
reasons
already stated.
What's wrong with javax?
On Friday, 13 June 2014 at 09:29:25 UTC, Jonathan M Davis via
Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed than have foreach(;
0..n) {} added.
Just out of curiosity, what is it you don't like about "for(;;)".
For what it's worth, I like using "for(;;)" a lot, because quite
On 6/12/14, 9:41 PM, Nick Sabalausky wrote:
On 6/12/2014 8:36 PM, Ary Borenszweig wrote:
You normally do that by using names that the grammar doesn't allow as
valid identifiers. Then you have a counter and prepend that. This way
you never have name collisions.
And doesn't DMD *already* do a l
On 06/12/2014 06:59 PM, bearophile wrote:
Nick Treleaven:
there is also this usage:
foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Have you ever used void[0][T]?
On 13 June 2014 19:15, Jonathan M Davis via Digitalmars-d
wrote:
> On Fri, 13 Jun 2014 01:00:11 +1000
> Manu via Digitalmars-d wrote:
>
>> I often find myself wanting to write this:
>> foreach(; 0..n) {}
>> In the case that I just want to do something n times and I don't
>> actually care about
On 13/06/2014 3:00 a.m., Manu via Digitalmars-d wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You can do this:
for(;;) {}
If 'for' lets y
On Friday, 13 June 2014 at 12:01:00 UTC, Tom Browder via
Digitalmars-d wrote:
On Wed, Jun 4, 2014 at 4:12 PM, Brian Schott via Digitalmars-d
wrote:
I've been looking at ways to optimize the D lexer's operation
using SIMD
Brian, i just found the lexer code repo (and fixed the broken
code
link
On Wed, Jun 4, 2014 at 4:12 PM, Brian Schott via Digitalmars-d
wrote:
> I've been looking at ways to optimize the D lexer's operation using SIMD
Brian, i just found the lexer code repo (and fixed the broken code
link on the wiki), but the review thread on the wiki looks very old.
The wiki page:
On Thursday, 12 June 2014 at 15:00:20 UTC, Manu via Digitalmars-d
wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You can do this:
for(;;) {}
On 13/06/14 11:28, "Marc Schütz" " wrote:
Would be nice if we could elide the parentheses and semicolons:
10.times! {
writeln("Do It!");
}
10.times! (uint n) {
writeln(n + 1, " Round");
}
Yeah, that has been suggested before.
--
/Jacob Carlborg
On Friday, 13 June 2014 at 09:29:25 UTC, Jonathan M Davis via
Digitalmars-d wrote:
I'd honestly rather see for(;;) {} removed than have foreach(;
0..n) {} added.
I don't like special cases like like these.
And I really don't think that it's a big deal to have to
provide a counter
variable that
13-Jun-2014 12:22, Rainer Schuetze пишет:
On 13.06.2014 02:38, Dmitry Olshansky wrote:
12-Jun-2014 10:34, Rainer Schuetze пишет:
I implemented the QueryWorkingSetEx version like this (you need a
converted psapi.lib for Win32):
Yes, exactly, but I forgot the recipe to convert COFF/OMF impor
I like them !
Do you want to create a doodle or a form so people can vote ?
On Thursday, 12 June 2014 at 22:38:26 UTC, Daniel Kozák via
Digitalmars-d wrote:
No problem for me:
http://stackoverflow.com/questions/23950796/how-to-repeat-a-statement-n-times-simple-loop/23952012#23952012
Would be nice if we could elide the parentheses and semicolons:
10.times! {
On Thursday, 12 June 2014 at 16:59:34 UTC, bearophile wrote:
Nick Treleaven:
there is also this usage:
foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used
it so far.
Would enforcing immutability there be a breaking change?
foreach (/*immutable*/
On Fri, 13 Jun 2014 01:00:11 +1000
Manu via Digitalmars-d wrote:
> I often find myself wanting to write this:
> foreach(; 0..n) {}
> In the case that I just want to do something n times and I don't
> actually care about the loop counter, but this doesn't compile.
>
> You can do this:
> for(;;
On 06/13/2014 04:03 AM, Steven Schveighoffer via Digitalmars-d wrote:
> On Thu, 12 Jun 2014 21:22:25 -0400, Kapps wrote:
>
>> I could be wrong about this, but from what I remember this comes down
>> to DMC's runtime library. The max number of open file descriptors
>> with apis such as fopen is pre
On 13.06.2014 02:38, Dmitry Olshansky wrote:
12-Jun-2014 10:34, Rainer Schuetze пишет:
I implemented the QueryWorkingSetEx version like this (you need a
converted psapi.lib for Win32):
Yes, exactly, but I forgot the recipe to convert COFF/OMF import libraries.
Grab coffimplib.exe.
This
Walter Bright:
https://github.com/D-Programming-Language/druntime/pull/839
Yes, I know others are interested in this, too!
Just like the safe removal of unnecessary array bound tests, it
is also good to have some logic in the compiler to safely remove
overflow tests. A possible start point
On 12/06/14 17:00, Manu via Digitalmars-d wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You can do this:
for(;;) {}
If 'for' lets you omi
On 12/06/14 21:21, Nick Sabalausky wrote:
- I rarely need to do that. Most of my "N times" loops exist *because* I
want to use the index.
I use the "n.times" in Ruby for testing quite a lot. When I need to
create x instances of a class and it doesn't matter what values they
have. Although I
On 13/06/14 07:26, Tolga Cakiroglu wrote:
In the download page, table shows for which CPU type they are available.
dmd.2.065.0.zip shows i386 and x86_64. So, this should run on 32 and
64-bits.
dmd.2.065.0.dmg shows only x86_64 which is for 64-bit CPU only.
That's not correct. The zip file only
67 matches
Mail list logo
