On 12/30/16 9:32 PM, David Zhang wrote:
On Saturday, 31 December 2016 at 02:03:07 UTC, rikki cattermole wrote:
As it should, current is never reassigned.
You only need one var, next. Of course I didn't read the entire thread
chain so, I'm probably missing something.
import
On Saturday, 31 December 2016 at 02:36:01 UTC, rikki cattermole
wrote:
No, my understand is thus:
next = current.next;
theAllocator.dispose(current);
When current is deallocated, current is pointing to free'd
memory.
After that point it should be segfaulting when you try to
access it *I
On 31/12/2016 3:32 PM, David Zhang wrote:
On Saturday, 31 December 2016 at 02:03:07 UTC, rikki cattermole wrote:
As it should, current is never reassigned.
You only need one var, next. Of course I didn't read the entire thread
chain so, I'm probably missing something.
import
On Saturday, 31 December 2016 at 02:03:07 UTC, rikki cattermole
wrote:
As it should, current is never reassigned.
You only need one var, next. Of course I didn't read the entire
thread chain so, I'm probably missing something.
import std.experimental.allocator;
void main() {
struct S
On 31/12/2016 2:52 PM, David Zhang wrote:
Extracting everything into a main() also causes the application to hang.
ie:
struct S
{
S* next;
}
S* _foo;
foreach (e; 0 .. 10)
_foo = theAllocator.make!S(_foo);
S* next, current;
next = current = _foo;
while (next)
{
next =
Extracting everything into a main() also causes the application
to hang.
ie:
struct S
{
S* next;
}
S* _foo;
foreach (e; 0 .. 10)
_foo = theAllocator.make!S(_foo);
S* next, current;
next = current = _foo;
while (next)
{
next = current.next;
theAllocator.dispose(current);
}
On Friday, 30 December 2016 at 22:42:07 UTC, Steven Schveighoffer
wrote:
What is actually happening is that the D main function returns.
Then the D runtime tears down everything, including joining all
threads, running all module static dtors, terminating the GC,
etc.
Then it returns to the
On 12/30/16 4:31 PM, David Zhang wrote:
@Steven, the process hangs after the "All unit tests have been
successfully", after which the process is supposed to exit immediately.
What is actually happening is that the D main function returns. Then the
D runtime tears down everything, including
On Friday, 30 December 2016 at 20:59:30 UTC, Seb wrote:
On Friday, 30 December 2016 at 18:03:44 UTC, David Zhang wrote:
On Friday, 30 December 2016 at 14:12:35 UTC, Steven
Schveighoffer wrote:
[snip]
It depends on what is actually hanging the process. If it's
something in your code base
On Friday, 30 December 2016 at 18:03:44 UTC, David Zhang wrote:
On Friday, 30 December 2016 at 14:12:35 UTC, Steven
Schveighoffer wrote:
[snip]
It depends on what is actually hanging the process. If it's
something in your code base only, then nobody else would be
seeing it.
-Steve
So,
On 12/30/16 1:03 PM, David Zhang wrote:
On Friday, 30 December 2016 at 14:12:35 UTC, Steven Schveighoffer wrote:
[snip]
It depends on what is actually hanging the process. If it's something
in your code base only, then nobody else would be seeing it.
So, what should I do with it? I'd submit
On Friday, 30 December 2016 at 14:12:35 UTC, Steven Schveighoffer
wrote:
[snip]
It depends on what is actually hanging the process. If it's
something in your code base only, then nobody else would be
seeing it.
-Steve
So, what should I do with it? I'd submit a bug report, but I
don't know
On 12/29/16 8:33 PM, David Zhang wrote:
On Friday, 30 December 2016 at 01:25:50 UTC, Steven Schveighoffer wrote:
Looks like that comes from here:
https://github.com/dlang/dub/blob/master/source/dub/dub.d#L577
I have serious doubts that this is the correct way to run tests, as
share ctors are
On Friday, 30 December 2016 at 01:25:50 UTC, Steven Schveighoffer
wrote:
Looks like that comes from here:
https://github.com/dlang/dub/blob/master/source/dub/dub.d#L577
I have serious doubts that this is the correct way to run
tests, as share ctors are supposed to have run BEFORE unit
tests
On 12/29/16 7:49 PM, David Zhang wrote:
On Friday, 30 December 2016 at 00:44:50 UTC, Steven Schveighoffer wrote:
Where does the "All unit tests have been completed successfully."
message come from? That's not standard D, which prints nothing.
I should have mentioned that I use dub then,
On Friday, 30 December 2016 at 00:44:50 UTC, Steven Schveighoffer
wrote:
Where does the "All unit tests have been completed
successfully." message come from? That's not standard D, which
prints nothing.
-Steve
I should have mentioned that I use dub then, shouldn't I? Anyway,
this is what
On 12/29/16 3:27 PM, David Zhang wrote:
Hi,
I've noticed recently, that whenever I unittest, it program hangs either
at the very end, or right before they start. When using vanilla unit
tests, the program appears to hang after the "All unit tests have been
completed successfully." message, and
On Thursday, 29 December 2016 at 20:50:54 UTC, David Zhang wrote:
On Thursday, 29 December 2016 at 20:33:33 UTC, Stefan Koch
wrote:
It would be very helpful if you could provide example code
that triggers that behavior.
I'd love to, but I'm not actually sure just what it is that
breaks it.
On Thursday, 29 December 2016 at 20:33:33 UTC, Stefan Koch wrote:
It would be very helpful if you could provide example code that
triggers that behavior.
I'd love to, but I'm not actually sure just what it is that
breaks it. I can provide the git repo for one of them though
though:
On Thursday, 29 December 2016 at 20:27:21 UTC, David Zhang wrote:
Hi,
I've noticed recently, that whenever I unittest, it program
hangs either at the very end, or right before they start. When
using vanilla unit tests, the program appears to hang after the
"All unit tests have been
20 matches
Mail list logo
