Re: GC deadlocks on linux
On Sat, 28 Feb 2015 06:09:16 +0100, Martin Nowak wrote: Meanwhile the author of daemonized came up with another idea, using exec instead of fork. https://github.com/NCrashed/daemonize/issues/2 ahem. http://forum.dlang.org/post/mc35ap$2dvo$5...@digitalmars.com signature.asc Description: PGP signature
Re: GC deadlocks on linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2015 09:27 PM, Byron Heads wrote: I have a medium size daemon application that uses several threads, libasync, and daemonize. On windows it runs correctly with GC enabled, but on linux the GC causes a deadlock while allocating memory. Have you been able to resolve the issue? There were a number of suggestions in the thread, but we never heard back from you. Meanwhile the author of daemonized came up with another idea, using exec instead of fork. https://github.com/NCrashed/daemonize/issues/2 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8U14AAoJELJzgRYSuxk5wnEP/R6nFZECdFsNSFK/Bmsys5WI RmYt8FyS5WJt/2tM/jKgN6k5WJLP+ZniSHPTMdWO4pGxJTaK6zGvMXVYEHPFgIDp RPcJhZ/J1KXyfOyR3by/23opvGaWqAJXIx3yBfYBhvjNNpjQrGxqQEwdT4sbDvz1 AtUZ+Tc1CoBo+3hRNESyk9FNa3c58adu5SWkpErJezrg4TFzYg7sKytbZEtb5T6U OWLVlMqY8Q6AyskbEUqxfQt8lba9fM5Eeg8gbzf7ShCZwrzviBkrhdTWrodv8kHo HeMZmRIBKmz/L0Ce/7NSV+U0htEB+DAB2LSYRKhy/qYwoLHi8UNruqv3pf4PU7Ly 4atq5XTcFNS/ywL8qkP8OMmcdBN0pBQNsDfmG2w1DsWANtK/cLqwS50O8TXCxpv1 hlQ/CgRD6jJWujleaDOhuOZWYzJ0Xwk1a5BGjoO5MkQaHeRZgalSN4rkmoPZQz1t H2kA03JMTVkEx2AllPKHdQCcNEV0wpI7sJNRWh9kewtdzW0SQtlV2NYM9U2gXPJe u+zYuWRLGpWOrqItzZGt+Z+NSrNziV0cO/IpogQRjMPtLXsRgaFofzaOO81l7OWk SWnE3bT2PO2sdZ0Z3uf/c+KAosDJ+5AhD9FXmuEemIc4S4/1yKJSVj7BtsomBxE+ hGfLvRuNjUDQil+WjC0t =MNgH -END PGP SIGNATURE-
Re: Does static ctor/dtor of struct behave differently in 2.067-b2?
On Fri, 27 Feb 2015 23:58:16 +, amber wrote:
On Friday, 27 February 2015 at 23:50:51 UTC, amber wrote:
Hi All,
[snip]
Thanks, amber
[edited subject]
Sorry I should add that I'm talking about static ctor/dtor of struct.
The bug I see with 2.067-b2 is this:
1. static this() {} called and static fields of struct are initialised
2. app runs, static fields are initialised.
3. static ~this() {} called and static fields of struct are NOT
initialised.
In step 3 with 2.066.1 all the static fields of struct are still
initialised, as expected, and my app shuts down cleanly.
is your struct GC-allocated? and can you provide dustmited code or
something we can play with?
signature.asc
Description: PGP signature
DMD Zip for Mac OS X
I'm not a Mac user and I'm fairly clueless about it. The DMD zip for OS X contains one executable. I assume it's a 64-bit binary. Is that true?
Re: @trusted and return ref
On 2/27/15 3:29 AM, Kagamin wrote: On Thursday, 26 February 2015 at 16:25:59 UTC, Steven Schveighoffer wrote: However, we have an issue here. At any point inside the code, you could do: oldcount = count; And now, there is still potentially a dangling pointer somewhere. This means every place count is used must be checked. In this case, all uses of count have to be re-checked when the file is edited. Because count leaks the memory details of the trusted call to free (In other words, the fact that count, or any copy of it, can become a dangling pointer), I believe every call in that type that deals with count should be marked trusted. The counter is freed in the destructor, nothing can happen after that. So the code is now etched in stone and cannot be changed? Is there an attribute for that? :P -Steve
Re: @trusted and return ref
On Friday, 27 February 2015 at 10:49:25 UTC, Ola Fosheim Grøstad wrote: 2. You construct a transform T(x) that can transform language D into x. = D is proven safe. Eh: 2. You construct a transform T(x) that can transform programs in language D into P...
Re: 3 dimension arrays
On Thursday, 26 February 2015 at 23:25:22 UTC, Ali Çehreli wrote:
On 02/26/2015 12:01 PM, Andrey wrote: HI guys!!!
Have a problem with 3d array memory allocation in next code:
//
class NeuronNet(T, const uint layersNum)
{
T[]_inputs;
T[][layersNum - 2]_hidden;
T[]_outputs;
T[]_target;
//waights [col][row][dimension]
T[][][layersNum - 1] _waightsArray;
(Unrelated: That may be a typo if its actually weights.)
this(in uint[] nodesArr)
{
//values init
_inputs = new T[nodesArr[0]];
_outputs = new T[nodesArr[$-1]];
for(uint j = 0; j layersNum - 2; j++)
Better:
foreach (j; 0 .. layersNum - 2)
{
_hidden[][j] = new T[nodesArr[j + 1]];
You have extra [] up there. This is equivalent:
_hidden[j] = new T[nodesArr[j + 1]];
The reason is, _hidden[] means the entire _hidden slice
anyway. So, the empty [] has no meaning at all.
}
//waights init
for(uint i = 0; i layersNum - 1; i++)
{
_waightsArray[][][i] = new T[][nodesArr[1+i]];
Same there:
_waightsArray[i] = new T[][nodesArr[1+i]];
for(uint ii = 0; ii nodesArr[1+i]; ii++)
{
_waightsArray[][ii][i] = new T[nodesArr[i]];
You want to set ii'th element of the i'th element, right? This
is the right way to do it in D:
_waightsArray[i][ii] = ...
Unlike C and C++, the array syntax is natural in D. In other
words, it is not inside out.
T[] -- A slice of Ts
T[][] -- A slice of T slices
T[][][layersNum - 1] -- A number of those
So, _waightsArray[i] is one of the slices that you've just set
in the previous for loop.
Ali
I very much appreciate. The author of D-book respond to me.
THANKS VERY MUCH!
Re: On opCmp
On Friday, 27 February 2015 at 11:04:51 UTC, Nordlöw wrote:
Is there a more compact way to describe the opCmp function in
the following struct
struct Hit
{
size_t count; // number of walkers that found this node
NWeight rank; // rank (either minimum distance or maximum
strength)
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
if (this.rank rhs.rank)
{
return -1;
}
else if (this.rank rhs.rank)
{
return +1;
}
else
{
return 0;
}
}
}
}
by reusing something like
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
return this.rank.standardOpCmp(rhs.rank)
}
}
Two things come to mind:
A) std.algorithm.cmp
auto opCmp(const Hit rhs) const
{
import std.algorithm: cmp;
import std.range: only;
if(auto c = cmp(only(count), only(rhs.count)))
{
return c;
}
else /* 'count' values are equal. */
{
return cmp(only(rank), only(rhs.rank));
}
}
Maybe there should be a std.algorithm.cmp for non-ranges, too, so
that `only` wouldn't be needed here.
B) std.typecons.Tuple has an opCmp that compares all fields in
order.
auto opCmp(const Hit rhs) const
{
import std.typecons: tuple;
return tuple(count, rank).opCmp(tuple(rhs.count, rhs.rank));
}
This exact behaviour is not documented, though. So I guess it
should not be relied on. Maybe the documentation should be more
specific. In the meantime, you could duplicate the functionality
in a function of your own:
import std.typecons: Tuple;
/** Put a proper, specific description here.
*/
int cmpTuples(Types ...)(Tuple!Types a, Tuple!Types b)
{
// copied from std.typecons.Tuple.opCmp
foreach (i, Unused; Types)
{
if (a[i] != b[i])
{
return a[i] b[i] ? -1 : 1;
}
}
return 0;
}
struct Hit
{
size_t count;
NWeight rank;
auto opCmp(const Hit rhs) const
{
import std.typecons: tuple;
return cmpTuples(tuple(count, rank), tuple(rhs.count,
rhs.rank));
}
}
Re: Will D have a serious dedicated well supported IDE like Visual Studio or Eclipse?
On Fri, 2015-02-27 at 04:12 +, AJ via Digitalmars-d-learn wrote: […] I am in the same boat and totally agree. It's tough going from the user-experience of IntelliJ IDEA or Visual Studio back to vi on OS X with D. There seems to be a large hole in support for D debugging outside of Visual D (line numbers, variable values, etc). I was hoping to use D for a new project, but I don't feel the tools are ready yet. Kingsley Hendrickse is developing a D plugin for IntelliJ IDEA. Should also work with CLion. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Will D have a serious dedicated well supported IDE like Visual Studio or Eclipse?
On Friday, 27 February 2015 at 07:08:26 UTC, Ali Çehreli wrote: What version of gdb is needed and is that version easy to install? Something from late 2014 or newer is the best (7.8.50-cvs or 7.9.50-cvs) as it has got Ian's patches merged, but even an old stock Debian gdb (7.4.1) works reasonably well. GDB is acually easy to install if you compile it yourself. Just copy the binary to /usr/local/bin.
Re: On opCmp
On 2/27/15 6:04 AM, Nordlöw wrote:
Is there a more compact way to describe the opCmp function in the
following struct
struct Hit
{
size_t count; // number of walkers that found this node
NWeight rank; // rank (either minimum distance or maximum strength)
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
if (this.rank rhs.rank)
{
return -1;
}
else if (this.rank rhs.rank)
{
return +1;
}
else
{
return 0;
}
}
}
}
Hm... what about:
return count rhs.count ? -1 : count rhs.count ? 1 : rank rhs.rank
? -1 : rank rhs.rank;
by reusing something like
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
return this.rank.standardOpCmp(rhs.rank)
}
}
A standard opCmp would be nice. Why wouldn't you use it for count as well?
-Steve
Re: On opCmp
On 02/27/2015 03:04 AM, Nordlöw wrote: Is there a more compact way to describe the opCmp function in the following struct Please see: http://forum.dlang.org/thread/lnr99a$vvd$1...@digitalmars.com#post-lnr99a:24vvd:241:40digitalmars.com Ali
Re: @trusted and return ref
On Friday, 27 February 2015 at 08:34:24 UTC, Kagamin wrote: @safe is supposed to provide safety, if you can give an example when it doesn't, you can report a bug. There are indeed bugs in implementation of safety, like escaping of local variables, but they are supposed to be fixed eventually. The bug is in using an approach that does not use proofs.
Re: @trusted and return ref
If you can't give an example of unsafety easily, that's already quite important. Compare to C, where one can provide such an example easily. If you want to write a mathematical prover, that won't hurt, though such tools don't need language support, lints and provers were written even for C.
Re: @trusted and return ref
On Thursday, 26 February 2015 at 16:25:59 UTC, Steven Schveighoffer wrote: However, we have an issue here. At any point inside the code, you could do: oldcount = count; And now, there is still potentially a dangling pointer somewhere. This means every place count is used must be checked. In this case, all uses of count have to be re-checked when the file is edited. Because count leaks the memory details of the trusted call to free (In other words, the fact that count, or any copy of it, can become a dangling pointer), I believe every call in that type that deals with count should be marked trusted. The counter is freed in the destructor, nothing can happen after that.
Re: @trusted and return ref
On Thursday, 26 February 2015 at 20:56:52 UTC, Ola Fosheim Grøstad wrote: Well, but @safe code is not verified either... It is inferred @safe based on a fixed set of criterions, but not verified. To verify you need more, and you have to start with strong typing. @safe is supposed to provide safety, if you can give an example when it doesn't, you can report a bug. There are indeed bugs in implementation of safety, like escaping of local variables, but they are supposed to be fixed eventually.
Re: @trusted and return ref
On Friday, 27 February 2015 at 09:33:43 UTC, Kagamin wrote: If you can't give an example of unsafety easily, that's already quite important. Compare to C, where one can provide such an example easily. Yes, that is true. Also, if you are conservative in C++ you also get pretty good safety with unique_ptr etc. So weak memory safety is ok, but then I also think it is ok to provide @trusted convenience since you are already saying that the programmer is competent: unsafe_malloc!T() unsafe_free!T() unsafe_memmove!T() unsafe_mmap… If you want to write a mathematical prover, that won't hurt, though such tools don't need language support, lints and provers were written even for C. Yep. But what I meant is that a type system (including memory safety) ought to be proven sound. I.e: 1. You construct a simple language/type-system P and prove that P is sound and safe. 2. You construct a transform T(x) that can transform language D into x. = D is proven safe.
On opCmp
Is there a more compact way to describe the opCmp function in the
following struct
struct Hit
{
size_t count; // number of walkers that found this node
NWeight rank; // rank (either minimum distance or maximum
strength)
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
if (this.rank rhs.rank)
{
return -1;
}
else if (this.rank rhs.rank)
{
return +1;
}
else
{
return 0;
}
}
}
}
by reusing something like
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
return this.rank.standardOpCmp(rhs.rank)
}
}
Does static ctor/dtor behave differently in 2.067-b2?
Hi All,
I am just wondering if dmd 2067-b2 invokes static this() and
static ~this() differently to 2066.1
I have a strange bug when I use DMD2.067-b2 and it looks a lot
like the static ctor/dtor are run from a separate thread to
main() and unittest{} blocks. When I run under 2066.1 the code
works correcly and behaves as if everything runs in the same
thread (which is what I am expecting).
It's difficult to be sure because thisTid under 2067 returns an
actual ID but under 2066.1 it always returns
Tid(std.concurrency.MessageBox)
The code below doesn't have the bug but it's what I'm using to
try and figure out the difference between 2066.1 and 2067.
---
import std.concurrency;
import std.stdio;
struct S
{
static int val = 1;
static this(){
writefln(Ctor:%s, thisTid);
val = 2;
}
static ~this() {
writefln(Dtor:%s, thisTid);
val = 0;
}
}
unittest {
S s;
writefln(UT -- s:%s tid:%s, S.val, thisTid);
}
void main() {
S s;
writefln(MAIN -- s:%s tid:%s, S.val, thisTid);
}
---
Thanks,
amber
Re: Does static ctor/dtor of struct behave differently in 2.067-b2?
On Friday, 27 February 2015 at 23:50:51 UTC, amber wrote:
Hi All,
[snip]
Thanks,
amber
[edited subject]
Sorry I should add that I'm talking about static ctor/dtor of
struct.
The bug I see with 2.067-b2 is this:
1. static this() {} called and static fields of struct are
initialised
2. app runs, static fields are initialised.
3. static ~this() {} called and static fields of struct are NOT
initialised.
In step 3 with 2.066.1 all the static fields of struct are still
initialised, as expected, and my app shuts down cleanly.
Thanks,
amber
Re: Getting what came *before* the results of a find call
Not that it's super important, but the link didn't copy well, so here's that: http://www.informit.com/articles/article.aspx?p=1407357seqNum=12
Re: Getting what came *before* the results of a find call
On Friday, February 27, 2015 14:42:17 Ali Çehreli via Digitalmars-d-learn wrote:
On 02/27/2015 02:29 PM, Mark Isaacson wrote:
What's the idiomatic way of getting everything *before* the results of a
call to find?
assert(hello world.find( world).what_goes_here??? == hello);
In an article Andrei wrote a few years ago
(http://www.informit.com/articles/article.aspx…) he mentioned a function
like this with the name until, but I can't find it or its replacement
in Phobos.
findSplit and friends in std.algorithm:
import std.algorithm;
void main()
{
assert(hello world.findSplit( world)[0] == hello);
}
There's also std.algorithm.until if all you want is what's before, whereas
findSplit gives you both what's before and after.
- Jonathan M Davis
Getting what came *before* the results of a find call
What's the idiomatic way of getting everything *before* the results of a call to find? assert(hello world.find( world).what_goes_here??? == hello); In an article Andrei wrote a few years ago (http://www.informit.com/articles/article.aspx…) he mentioned a function like this with the name until, but I can't find it or its replacement in Phobos.
Re: Getting what came *before* the results of a find call
Ahhh right - forgot about that. Thanks!
Re: Getting what came *before* the results of a find call
On 02/27/2015 02:29 PM, Mark Isaacson wrote:
What's the idiomatic way of getting everything *before* the results of a
call to find?
assert(hello world.find( world).what_goes_here??? == hello);
In an article Andrei wrote a few years ago
(http://www.informit.com/articles/article.aspx…) he mentioned a function
like this with the name until, but I can't find it or its replacement
in Phobos.
findSplit and friends in std.algorithm:
import std.algorithm;
void main()
{
assert(hello world.findSplit( world)[0] == hello);
}
Ali
