On Friday, 24 February 2017 at 06:59:16 UTC, Jack Stouffer wrote:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
[...]
This isn't evidence that memory safety is "the future", though.
This is evidence that people do not follow basic engineering
practices (for whatever
On Thursday, 23 February 2017 at 22:55:05 UTC, Sönke Ludwig wrote:
The virtual server that is running code.dlang.org has frozen
about an hour ago and fails to boot further than to the
bootloader. Initial attempts to recover from within Grub have
failed and it's unclear what the root cause is.
On Wednesday, 22 February 2017 at 05:28:17 UTC, Alex wrote:
[...]
In both gdc and dmd I need to use manually delete this object
or the program is blocked after main. Is by design ?
Yes, it's documented here[1] (others have already replied on the
GC subject, so I won't go into that). If you
On Monday, 20 February 2017 at 12:47:43 UTC, berni wrote:
pragma(inline, true) doesn't work out well:
int bar;
void main(string[] args)
{
if (foo()) {}
}
bool foo()
{
pragma(inline, true)
if (bar==1) return false;
if (bar==2) return false;
return true;
}
with
dmd -inline
On Sunday, 19 February 2017 at 01:52:07 UTC, Stefan Koch wrote:
On Saturday, 18 February 2017 at 22:40:44 UTC, Moritz Maxeiner
wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
Hi Guys, due to the old CTFE status thread getting to page
30, I am now starting a new one.
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
Hi Guys, due to the old CTFE status thread getting to page 30,
I am now starting a new one.
[...]
Thank you for your continued work on this. I heavily rely on D's
CTFE functionality and I try to read all your updates on it.
On Friday, 17 February 2017 at 20:06:19 UTC, berni wrote:
I wonder if it's possible to do something like this:
import std.stdio;
void main(string[] args)
{
if (args[1]=="a")
{
write("A");
scope (exit) write("B");
}
write("C");
}
I expected the output to be ACB not
On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
My rudimentary knowledge of the D ecosystem tells me that there
is a GC in D, but that can be turned off. Is this correct?
Technically yes; you will lose core functionality, though, if you
do.
I don't have the complete list at
On Tuesday, 14 February 2017 at 14:27:05 UTC, Kagamin wrote:
On Monday, 13 February 2017 at 17:44:10 UTC, Moritz Maxeiner
wrote:
To be clear: While I might, in general, agree that using
shared methods only for thread safe methods seems to be a
sensible restriction, neither language nor
On Tuesday, 14 February 2017 at 13:01:44 UTC, Moritz Maxeiner
wrote:
Of course, I just wanted to point out that Kagamin's post
scriptum is a simplification I cannot agree with. As a best
practice? Sure. As a "never do it"? No.
Sorry for the double post, error in the above, please use this
On Tuesday, 14 February 2017 at 10:52:37 UTC, Johannes Pfau wrote:
The compiler of course can't require shared methods to be
thread-safe as it simply can't prove thread-safety in all
cases. This is like shared/trusted: You are supposed to make
sure that a function behaves as expected. The
On Monday, 13 February 2017 at 14:20:05 UTC, Kagamin wrote:
Thread unsafe methods shouldn't be marked shared, it doesn't
make sense. If you don't want to provide thread-safe interface,
don't mark methods as shared, so they will not be callable on a
shared instance and thus the user will be
On Monday, 13 February 2017 at 01:30:57 UTC, ag0aep6g wrote:
This doesn't make sense to me. b depends on a. If I run thread
1 alone, I can expect b to be 1, no? Thread 2 can then a) read
0, write 1; or b) read 1, write 2. How can b be 0 when the
writeln is executed?
An example like this
On Sunday, 12 February 2017 at 20:08:05 UTC, bitwise wrote:
It seems that methods qualified with 'shared' may be what
you're suggesting matches up with the 'bridge' I'm trying to
describe, but again, using the word 'shared' to mean both
'thread safe' and 'not thread safe' doesn't make sense.
On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko
wrote:
1. Why your company uses D?
a. D is the best
b. We like D
c. I like D and my company allowed me to use D
d. My head like D
e. Because marketing reasons
f. Because my company can be more efficient with D for some
New major release of `llvm-d` with some backwards-incompatible
API changes, please
read the release message for the details. Cliffnotes:
- Just `import llvm`
- Remove `LLVM.load`, (dynamically) link against the appropriate
library/libraries
- Set a D version `LLVM_Target_XyZ' for every LLVM
On Friday, 17 June 2016 at 14:29:57 UTC, Russel Winder wrote:
A priori, assuming I am not missing anything, this behaviour
seems entirely reasonable.
I agree that when using non-daemon threads (and I personally
think that should be the default) that it is. But I cannot bring
that into
So, I am probably overlooking something obvious, but here goes:
According to my understanding of daemon threads and what is
documented here[1],
this following program should terminate once the druntime shuts
down, as the thread working on the task is supposed to be a
daemon thread:
import
On Monday, 7 December 2015 at 17:39:14 UTC, Andrei Alexandrescu
wrote:
We're over 20% full and seats are going fast!
We planned to send an announcement when we're 50% sold out.
However, this time around registrations are coming quite a bit
quicker than before so we thought we'd keep you
On Thursday, 9 April 2015 at 18:28:46 UTC, Marco Leise wrote:
Am Wed, 08 Apr 2015 13:05:01 +
schrieb Szymon Gatner noem...@gmail.com:
On Wednesday, 8 April 2015 at 12:34:06 UTC, Paulo Pinto wrote:
Since then, I always favor spaces over tabs. One space is
always one space.
Not to
On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote:
On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:
On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:
I actually think that there are two large categories of
programmers: those like writing the same loops over
On Saturday, 14 March 2015 at 20:15:30 UTC, Walter Bright wrote:
I've often thought, as do many others here, that immutability
should be the default for variables.
Case (1) is what I'm talking about here. If it is made const,
then there are a couple ways forward in declaring a mutable
On Friday, 2 January 2015 at 11:47:47 UTC, Daniel Kozak wrote:
I always think that shared should be use to make variable
global across threads (similar to __gshared) with some
synchronize protection. But this code doesn't work (app is
stuck on _aaGetX or _aaRehash ):
But when I add
On Tuesday, 15 April 2014 at 11:04:42 UTC, Daniel Murphy wrote:
Manu via Digitalmars-d digitalmars-d@puremagic.com wrote in
message
news:mailman.9.1397553786.2763.digitalmar...@puremagic.com...
Huh? Do methods work now? Since when?
Since I needed them for DDMD.
Is this[1] then out of
On Wednesday, 16 April 2014 at 14:00:24 UTC, Daniel Murphy wrote:
Moritz Maxeiner wrote in message
news:kvzwlecwougswrqka...@forum.dlang.org...
Is this[1] then out of date and I can interface with
non-virtual methods? Because that's what your post seems to
imply (unless I misunderstood).
501 - 525 of 525 matches
Mail list logo
