Re: getting member functions of a struct and Error: identifier expected following ., not this

[aliak via Digitalmars-d-learn]

On Tuesday, 23 January 2018 at 00:00:38 UTC, aliak wrote:

Hi, I'm trying to get a list of only member functions of a [...]
Cheers


And a follow up question: should I be using static foreach in 
there instead of a normal foreach? i.e.


foreach (member; __traits(allMembers, T)) {{
// same code
}}

And why if yes

Thanks again!

getting member functions of a struct and Error: identifier expected following ., not this

[aliak via Digitalmars-d-learn]

Hi, I'm trying to get a list of only member functions of a 
struct. I've found that if you do not declare a struct as static 
inside a scope, then there's a hidden "this" member as part of 
the struct. Can someone explain the logic there?


Also am I going about this correctly?

template MemberFunctions(T) {
import std.traits: isFunction;
auto MemberFunctions() {
string[] memberFunctions;
foreach (member; __traits(allMembers, T)) {

// NOTE: This static if is here is because of that 
hidden "this" member

//
// if I do not do this then I get:
//   Error: identifier expected following ., not this

static if (is(typeof(mixin("T." ~ member)) F))
if (isFunction!F) {
memberFunctions ~= member;
}
}
return memberFunctions;
}
}

unittest {
// works for static and non static.
/* static */ struct A {
void opCall() {}
void g() {}
}

/* static */ struct B {
int m;
A a;
alias a this;
void f() {}
}

static assert(MemberFunctions!B == ["f"]);
}

Cheers

dub infinite loop

[Arun Chandrasekaran via Digitalmars-d-learn]

So dub gets into indefinite loop (let's not argue about 
infinite/indefinite).


I've reported the issue a month back here 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/16888/ and recently here https://github.com/dlang/dub/issues/1345


Does anyone face the same issue? How do you work around this for 
a non trivial setup?

Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

[John Gabriele via Digitalmars-d-learn]

On Monday, 22 January 2018 at 15:32:29 UTC, Adam D. Ruppe wrote:

On Monday, 22 January 2018 at 15:18:38 UTC, Johann wrote:

Maybe it's due to historical reasons.


It's actually "future" reasons... the /phobos is the original 
one, and /library was supposed to replace it, but now many 
years later, /library is still kinda neglected and they both 
just exist.


What's needed to remove the "/phobos" one? Is it a decision from 
on-high, or is there a lot of editing of hardcoded links required?


This is a reason why I forked the d docs to my site 
dpldocs.info. Check out its search:


http://dpldocs.info/writef

But yeah, the link in the original source is hardcoded for the 
/phobos path... but is also a relative link. So when generated 
on /library, it is just a 404. On my fork, I just fixed it, but 
/library tries to build from the master branch so they can't 
really just fix things without making sure it still works in 
both generators. what a mess.


I'm not sure I understand. What would it take to make the 
"/library" pages good enough that you wouldn't need 
?

Re: Get largest heap object at runtime? ...tracking the leak

[thedeemon via Digitalmars-d-learn]

On Monday, 22 January 2018 at 16:37:19 UTC, Andres Clari wrote:
All threads withing a process share the same heap, so whatever 
one thread allocated in that heap is not freed or reclaimed 
automatically when thread dies, it stays in the heap.


Well the destructor of some Json objects and strings should be 
called when the thread exits tho.


If some objects were on the stack of the thread proc, their 
destructors run, yes, as usual for leaving a scope. Strings don't 
have destructors, afaik.
Thread-local storage gets cleaned up too. But everything that 
lives in heap, stays there, until GC finds them. Objects in heap 
don't have any information on them  which thread they belong to.

Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 22 January 2018 at 16:08:38 UTC, Johann wrote:
Not related to this thread, but is something missing from this 
page? Only "index" is shown on this page.


No, that's just a random file. If something isn't linked from 
another page, it isn't supported... I have a lot of files in that 
directory from various steps in my development process (it is 
still called "experimental" cuz it isn't done yet) and I haven't 
cleaned them all up.

Re: Get largest heap object at runtime? ...tracking the leak

[Andres Clari via Digitalmars-d-learn]

On Monday, 22 January 2018 at 15:56:53 UTC, thedeemon wrote:

On Monday, 22 January 2018 at 06:48:00 UTC, Andres Clari wrote:
Not sure why "spawn" would leak like that tho. I would assume 
that once the thread exits, it would get destroyed and it's 
resources reclaimed, specially when I have calls to 
"GC.collect and GC.minimize".


All threads withing a process share the same heap, so whatever 
one thread allocated in that heap is not freed or reclaimed 
automatically when thread dies, it stays in the heap.


Well the destructor of some Json objects and strings should be 
called when the thread exits tho. Why wouldn’t the GC take care 
of this?

Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

[Johann via Digitalmars-d-learn]

On Monday, 22 January 2018 at 15:32:29 UTC, Adam D. Ruppe wrote:


http://dpldocs.info/writef


Thanks for your good work. I will file a bug report then.

Not related to this thread, but is something missing from this 
page? Only "index" is shown on this page.


http://dpldocs.info/experimental-docs/

Re: Get largest heap object at runtime? ...tracking the leak

[thedeemon via Digitalmars-d-learn]

On Monday, 22 January 2018 at 06:48:00 UTC, Andres Clari wrote:
Not sure why "spawn" would leak like that tho. I would assume 
that once the thread exits, it would get destroyed and it's 
resources reclaimed, specially when I have calls to "GC.collect 
and GC.minimize".


All threads withing a process share the same heap, so whatever 
one thread allocated in that heap is not freed or reclaimed 
automatically when thread dies, it stays in the heap.

Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 22 January 2018 at 15:18:38 UTC, Johann wrote:

Maybe it's due to historical reasons.


It's actually "future" reasons... the /phobos is the original 
one, and /library was supposed to replace it, but now many years 
later, /library is still kinda neglected and they both just exist.


This is a reason why I forked the d docs to my site dpldocs.info. 
Check out its search:


http://dpldocs.info/writef

But yeah, the link in the original source is hardcoded for the 
/phobos path... but is also a relative link. So when generated on 
/library, it is just a 404. On my fork, I just fixed it, but 
/library tries to build from the master branch so they can't 
really just fix things without making sure it still works in both 
generators. what a mess.


Or if both directories are intented to be used, I'll file a bug 
instead.


yeah that is prolly best

[dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

[Johann via Digitalmars-d-learn]

It seems that std library documentation lives in two different 
directories.


https://dlang.org/phobos/

https://dlang.org/library/

Maybe it's due to historical reasons. Problem is, when I search 
for a library function in Google, sometimes it points me to 
library directory, and sometimes it points me to phobos directory.


In fact, when I search "dlang writef", it shows me two urls most 
relevant.


1. https://dlang.org/library/std/stdio/writef.html

2. https://dlang.org/phobos/std_stdio.html

Clicking "format string" hyperlink on first url gives a 404 
error. 
https://dlang.org/library/std/stdio/std_format.html#format-string


The second url is correct. 
https://dlang.org/phobos/std_format.html#format-string


Is https://dlang.org/library/ deprecated? If so, is it possible 
to remove it so that it won't confuse noobs like me?


Or if both directories are intented to be used, I'll file a bug 
instead.