On 25 May 2015 01:10, "Timon Gehr via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On 05/25/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
>>
>>
>> > This comes up once in a while. We should stick with left to right
>> through and through. It's a "simple" matter of getting somebod
On 25/05/2015 9:32 a.m., Liam McSherry wrote:
A first draft of the interfaces is available here:
https://github.com/McSherry/phobos/blob/std.archive/std/archive/interfaces.d
Please feel free to tear to pieces, make suggestions, etc.
I'm impressed an interface has been started!
Anyway, take
On 05/25/2015 01:49 AM, Andrei Alexandrescu wrote:
I think LTR is the most sensible in all cases. -- Andrei
It is also what Java and C# do.
On 5/24/15 3:36 PM, Iain Buclaw via Digitalmars-d wrote:
On 25 May 2015 00:20, "Andrei Alexandrescu via Digitalmars-d"
mailto:digitalmars-d@puremagic.com>> wrote:
>
> On 5/24/15 1:29 PM, Timon Gehr wrote:
>>
>> BTW, the documentation contradicts itself on evaluation order:
>> http://dlang.or
On 05/25/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
> This comes up once in a while. We should stick with left to right
through and through. It's a "simple" matter of getting somebody on the
compiler team to find the time for it. -- Andrei
>
I find it is not as clear cut as that. In
On 05/25/2015 12:15 AM, Andrei Alexandrescu wrote:
On 5/24/15 1:29 PM, Timon Gehr wrote:
BTW, the documentation contradicts itself on evaluation order:
http://dlang.org/expression.html
This comes up once in a while. We should stick with left to right
through and through. It's a "simple" matter
On Sunday, 24 May 2015 at 20:45:56 UTC, Laeeth Isharc wrote:
You might take a look at Vlad Levenfeld's work too, although I
think he would say that it is still at an early stage (if I
understand correctly - looks very interesting to me, although I
have not yet properly had time to explore it in
On 25 May 2015 00:20, "Andrei Alexandrescu via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On 5/24/15 1:29 PM, Timon Gehr wrote:
>>
>> BTW, the documentation contradicts itself on evaluation order:
>> http://dlang.org/expression.html
>
>
> This comes up once in a while. We should stick
On 24 May 2015 23:45, "weaselcat via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 24 May 2015 at 20:36:47 UTC, Laeeth Isharc wrote:
>>
>> Weaselcat:
>>
>>> FWIW I'm not picking on Rust, I used it for a rather long time(while in
beta, obviously) before I switched to D full tim
"Robbin" wrote in message news:yykhtfrfflbxdkuka...@forum.dlang.org...
Hi Robbin,
Problem 1 is defining the thread variable as a member of my ini class.
Since I have to use the auto t = thread(&parser), I can't figure out what
type to make t in the class. auto is no good without a rhs to giv
On 5/24/15 1:29 PM, Timon Gehr wrote:
BTW, the documentation contradicts itself on evaluation order:
http://dlang.org/expression.html
This comes up once in a while. We should stick with left to right
through and through. It's a "simple" matter of getting somebody on the
compiler team to find
On 24 May 2015 23:30, "Jonathan M Davis via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 24 May 2015 at 21:18:54 UTC, Timon Gehr wrote:
>>
>> The gcc backend obviously supports ordered operations, because some
operations are ordered today.
>
>
> Iain has talked in the past ab
On Sunday, 24 May 2015 at 20:36:47 UTC, Laeeth Isharc wrote:
Weaselcat:
FWIW I'm not picking on Rust, I used it for a rather long
time(while in beta, obviously) before I switched to D full
time for my academic work and I don't regret my decision. I
thought Rust would get more improvements tha
On Sunday, 24 May 2015 at 20:36:47 UTC, Laeeth Isharc wrote:
Without wishing to dwell on the negatives of alternatives,
might I ask what made you decide to settle on D? Do you have
collaborators who write code and, if so, how did the
discussions with them go about this? For your use case, wha
On 05/24/2015 11:26 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 21:18:54 UTC, Timon Gehr wrote:
The gcc backend obviously supports ordered operations, because some
operations are ordered today.
Iain has talked in the past about how they're forced to work around the
backend to force t
A first draft of the interfaces is available here:
https://github.com/McSherry/phobos/blob/std.archive/std/archive/interfaces.d
Please feel free to tear to pieces, make suggestions, etc.
On Sunday, 24 May 2015 at 21:18:54 UTC, Timon Gehr wrote:
The gcc backend obviously supports ordered operations, because
some operations are ordered today.
Iain has talked in the past about how they're forced to work
around the backend to force the order of operations for those
cases, and it'
On 05/24/2015 10:35 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 20:30:00 UTC, Timon Gehr wrote:
On 05/24/2015 09:48 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @propert
On Sun, 24 May 2015 15:40:04 -0400, bitwise wrote:
[snip]
So at this point, it seems like these two fixes work as expected, but
now, I'm having some new and very strange problems.
I have a simple shared library and program I've been using to test this:
[main.d]
module main;
import std.std
Self-criticism is necessary for improvement.
Yes, and what matters is after the storm has passed what you have
done with that energy. People with high standards and no
immediate ability to change things often complain a lot ;) To
this newcomer, at least, the progress is impressive.
On Sunday, 24 May 2015 at 17:46:40 UTC, Dennis Ritchie wrote:
Another good attempt to simplify operations with
multidimensional arrays and matrices:
https://github.com/k3kaimu/carbon/blob/master/source/carbon/linear.d
You might take a look at Vlad Levenfeld's work too, although I
think he wou
Weaselcat:
FWIW I'm not picking on Rust, I used it for a rather long
time(while in beta, obviously) before I switched to D full time
for my academic work and I don't regret my decision. I thought
Rust would get more improvements than it did. I feel like they
made so many poor decisions as the
On Sunday, 24 May 2015 at 20:30:00 UTC, Timon Gehr wrote:
On 05/24/2015 09:48 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf("array()\n"); return _array;
}
int
I am writing a daemon that parses an ini file and goes about its
business. In C++ I create a thread that does an inotify on the
ini file and when it changes, it locks the associative array that
contains the parsed ini file, reparses it and then does an unlock
and goes back to waiting for the i
On 05/24/2015 09:48 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf("array()\n"); return _array; }
int start() @property { printf("start()\n"); return 0; }
int e
On Sunday, 24 May 2015 at 19:48:05 UTC, Jonathan M Davis wrote:
The original code is clearly wrong. And forcing the order of
evaluation so that it's one way or the other just changes under
which cases you end up with bugs. Mutating in an expression
while using it multiple times in that expressi
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf("array()\n"); return _array; }
int start() @property { printf("start()\n"); return 0; }
int end() @property { printf("end()\n"); return 1;
I've read through these now, which I missed the first time around, so
sorry for making you guys repeat yourselves ;)
http://comments.gmane.org/gmane.comp.lang.d.runtime/1214
http://forum.dlang.org/thread/mailman.2052.1325532031.24802.digitalmar...@puremagic.com
So in terms of a shared lib h
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf("array()\n"); return _array; }
int start() @property { printf("start()\n"); return 0; }
int end() @property { printf("end()\n"); return 1; }
void main()
{
array[start..end] = 666;
pri
On Sunday, 24 May 2015 at 18:40:49 UTC, Paulo Pinto wrote:
On Sunday, 24 May 2015 at 17:22:26 UTC, bachmeier wrote:
On Sunday, 24 May 2015 at 11:59:00 UTC, Paulo Pinto wrote:
On Sunday, 24 May 2015 at 09:43:38 UTC, bachmeier wrote:
On Sunday, 24 May 2015 at 07:21:19 UTC, Joakim wrote:
Rust's
On Sunday, 24 May 2015 at 17:22:26 UTC, bachmeier wrote:
On Sunday, 24 May 2015 at 11:59:00 UTC, Paulo Pinto wrote:
On Sunday, 24 May 2015 at 09:43:38 UTC, bachmeier wrote:
On Sunday, 24 May 2015 at 07:21:19 UTC, Joakim wrote:
Rust's syntax dooms it to the same niche as Haskell.
They'd have
Another good attempt to simplify operations with multidimensional
arrays and matrices:
https://github.com/k3kaimu/carbon/blob/master/source/carbon/linear.d
On Saturday, 23 May 2015 at 05:17:13 UTC, Danni Coy wrote:
Got very close to a year or so ago. Probably something I would
be much
more capable of doing now. The only downside is that I enjoy
doing
asset creation more.
That's perfect, actually. Shoot me an email, we can all assemble
a D team a
Hello everyone!
I want to know whether there are any plans for the inclusion of
such a module in Phobos?
Documentation:
http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html
Source:
https://bitbucket.org/denis-sh/unstandard/src/ab5e199797e809ba4668affdc4fc8e84f40d2440/unstd/multid
On Sunday, 24 May 2015 at 11:59:00 UTC, Paulo Pinto wrote:
On Sunday, 24 May 2015 at 09:43:38 UTC, bachmeier wrote:
On Sunday, 24 May 2015 at 07:21:19 UTC, Joakim wrote:
Rust's syntax dooms it to the same niche as Haskell.
They'd have been better off to go with XML. I think the
developers go
On 5/24/15 1:20 AM, weaselcat wrote:
IMO I think the worst thing C++ has done is blatantly ignore features
that have been 'killer' in D(see: the reaction to the static_if proposal)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4461.html -- Andrei
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
Looks like a good step in the right direction.
Some questions about:
This provides a strong incentive to no longer use t
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
On Sunday, 24 May 2015 at 09:43:38 UTC, bachmeier wrote:
On Sunday, 24 May 2015 at 07:21:19 UTC, Joakim wrote:
Rust's syntax dooms it to the same niche as Haskell.
They'd have been better off to go with XML. I think the
developers got comfortable with the syntax as they went along,
and they
On Sunday, 24 May 2015 at 07:21:19 UTC, Joakim wrote:
Rust's syntax dooms it to the same niche as Haskell.
They'd have been better off to go with XML. I think the
developers got comfortable with the syntax as they went along,
and they have no idea just how ugly it is.
On Sunday, 24 May 2015 at 08:05:37 UTC, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 07:21:19 UTC, Joakim wrote:
It's a good sign that C++ has been copying D features
recently, it means they're feeling the heat.
I suspect that it's not so much that they're really feeling any
pressure fro
On Sunday, 24 May 2015 at 07:21:19 UTC, Joakim wrote:
It's a good sign that C++ has been copying D features recently,
it means they're feeling the heat.
I suspect that it's not so much that they're really feeling any
pressure from D so much as that when they see a cool feature that
they think
On Saturday, 23 May 2015 at 14:20:40 UTC, Russel Winder wrote:
On Fri, 2015-05-22 at 16:00 +, Jonathan M Davis via
Digitalmars-d
wrote:
On Friday, 22 May 2015 at 14:11:49 UTC, H. S. Teoh wrote:
> +1, finally, something other than the usual bickering on the
> forum. ;-)
LOL. Don't worry.
43 matches
Mail list logo
