Re: Two questions

[IM via Digitalmars-d-learn]

On Wednesday, 2 January 2019 at 17:49:52 UTC, H. S. Teoh wrote:
On Wed, Jan 02, 2019 at 05:38:41PM +, IM via 
Digitalmars-d-learn wrote:

1- How do I do in D the equivalent of the following C++ macro?

#define OUT_VAL(val) (count << #val << " = " << val << endl)

In particular the #val above to the actual macro argument as a 
string?

[...]

Try something along these lines:

import std.stdio;
void OUT_VAL(alias val)() {
writefln("%s = %s", __traits(identifier, val), val);
}
void main() {
int i = 123;
string s = "abc";
OUT_VAL!i;
OUT_VAL!s;
}


T


Thank you so much. Will give this a try.

Re: Two questions

[IM via Digitalmars-d-learn]

On Wednesday, 2 January 2019 at 21:56:03 UTC, Steven 
Schveighoffer wrote:

On 1/2/19 12:38 PM, IM wrote:


[...]


With those ... I have to guess.

There are 2 possibilities.

Possibility 1: there is a method named 'doSomeWork' which takes 
at least one parameter. This overrides the UFCS function 
(member functions always win over UFCS).


Possibility 2: All this is actually inside a function or 
unittest. Nested functions cannot participate in UFCS.




Perfect, this was it. Thank you so much. doSomeWork() was nested 
inside a unittest{} block. I didn't know UFCS won't work in this 
case.


Of course, these are guesses. But given the very scant code 
above, I'm not sure I could offer any other suggestions. If 
neither of those is the case, I'd need a working example.


-Steve

Two questions

[IM via Digitalmars-d-learn]

1- How do I do in D the equivalent of the following C++ macro?

#define OUT_VAL(val) (count << #val << " = " << val << endl)

In particular the #val above to the actual macro argument as a 
string?


2- Yesterday I was experimenting with something and I wrote 
something like the following:


struct MyType {
  ...
}

void doSomeWork(ref MyType o) {
   ...
}

auto t = MyType(...);

t.doSomeWork(); // <-- failed to compile.

Why did the above UFCS call fail to compile? I had to do 
doSomeWork(t) instead.


Thank you so much!

Re: DLS (D Language Server) v0.20

[IM via Digitalmars-d-announce]

On Friday, 28 December 2018 at 20:35:44 UTC, Paolo Invernizzi 
wrote:
On Friday, 28 December 2018 at 18:50:39 UTC, David Gileadi 
wrote:

On 12/28/18 4:14 AM, Laurent Tréguier wrote:

Hello, and merry Christmas! (a bit late, but whatever)


This is an excellent update--the update Just Works™ with 
VSCode on my mac, and functions very nicely too. Thanks!


I might suggest that you perhaps rename the VSCode extension 
to remove "VSCode" from the name (as it's redundant) and add 
"D Language" (because the current name makes it a bit hard to 
discover).


+1, It's a great piece of software, so thank you.



+100, Thank you very much!

I'm using it  on Mac also, when I'm not using vim: works like a 
charm!


--- Paolo

Re: Noob question about structs allocation

[IM via Digitalmars-d-learn]

On Monday, 15 October 2018 at 03:33:04 UTC, Basile B. wrote:

On Monday, 15 October 2018 at 03:19:07 UTC, IM wrote:
I probably used to know the answer to this question, but it's 
been a long time since I last used D, and I don't remember. 
Suppose we have:


struct S {
  int num;
}

Would allocating an instance on the heap using:

S* s = new S;

use the GC, or do we have to call destroy() or delete on s 
ourselves?


new is an operator that always allocates using the GC,
calling destroy yourself won't hurt either but is not necessary.


What is the effect of calling destroy?
- calling the destructor?
- deallocating the memory?
- both?

Noob question about structs allocation

[IM via Digitalmars-d-learn]

I probably used to know the answer to this question, but it's 
been a long time since I last used D, and I don't remember. 
Suppose we have:


struct S {
  int num;
}

Would allocating an instance on the heap using:

S* s = new S;

use the GC, or do we have to call destroy() or delete on s 
ourselves?

Re: Give DLS a try

[IM via Digitalmars-d]

On Wednesday, 8 August 2018 at 20:56:51 UTC, tide wrote:
On Wednesday, 8 August 2018 at 07:57:49 UTC, Laurent Tréguier 
wrote:

[...]


Code-d overcomplicates things I find though. I can't even build 
it, there's so many dependencies attached to it that it isn't 
worth looking through to even find which one is causing the 
build issue. Let alone there's a restriction that it can only 
build 32-bit. Also can't be built with LDC2 cause of the 
dependencies is trying to build a 64-bit binary even though the 
arch is set to 32-bit. It's a mess. DLS took no time at all to 
build, nice and simple. Just one thing is installing the 
extension didn't create that symbolic link for me. And the 
plugin just silently passes an empty path if it can't find DLS.


https://github.com/LaurentTreguier/vscode-dls/blob/master/src/extension.ts#L20


I've always had issues with Code-d! I filed several issues on its 
GitHub repo, but my experience with the Code-d author was that 
those issues are likely to remain open and unaddressed.


I switched to DLS and I'm much happier now. I'm glad we have 
options. So thanks for the hard work and keep it up!

Re: When will the final DConf videos surface on YouTube?

[IM via Digitalmars-d]

On Friday, 4 May 2018 at 00:13:42 UTC, Nick Sabalausky (Abscissa) 
wrote:

On 05/03/2018 05:09 PM, IM wrote:

I can't wait to watch.


Not sure if you're specifically talking about the videos being 
split up per talk, but you can rewatch the full first two days 
livestreams here:


Day 1 Afternoon (Apparently morning was lost, I hear):
https://www.youtube.com/watch?v=HvqsUO77FGI

Day 2:
https://www.youtube.com/watch?v=0UZuRNujLGQ


Yes, I'm asking about the split up videos per talk.

When will the final DConf videos surface on YouTube?

[IM via Digitalmars-d]

I can't wait to watch.

Re: Official Dub package for DWT

[IM via Digitalmars-d-announce]

On Wednesday, 7 February 2018 at 21:33:22 UTC, Jacob Carlborg 
wrote:
This has been long overdue but I would like to announce that 
I've just released an official Dub package for the DWT library 
[1]. For a usage example, please see the GitHub page [2].


[...]


This is great, thanks!
Any plans to make it link with gtk3 instead of 2? I remember gtk2 
had issues with HiDPI support.

Re: Release D 2.078.0

[IM via Digitalmars-d-announce]

On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:

Glad to announce D 2.078.0.

This release comes with runtime detection of Visual Studio 
installation paths, an integral promotion transition for unary 
operations on byte and short sized integers, more -betterC 
features, and a couple of language and library tweaks.


Thanks to everyone involved in this  
https://dlang.org/contributors.html.


http://downloads.dlang.org/releases/2.x/2.078.0/ 
http://dlang.org/changelog/2.078.0.html


- -Martin


Thank you very much!

Re: What don't you switch to GitHub issues

[IM via Digitalmars-d]

On Tuesday, 2 January 2018 at 16:32:50 UTC, H. S. Teoh wrote:
On Tue, Jan 02, 2018 at 09:57:08AM +, Patrick Schluter via 
Digitalmars-d wrote:

On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:

[...]
> I am just going to share my thoughts a little. Github, in my 
> opinion, is hype and even though I depend on it today, I am 
> trying to decrease that dependency. We should build a world 
> that is not dependent on single companies. I am not 
> downplaying what github has done for us (I am one of the 
> early users) - but they have just become a little too 
> important for free software to be comfortable. The github 
> issue tracker is wanting anyway.
> 
> D is a great language. I just spent 6 months in C++ and the 
> last month worked on a D multi-threaded project again. I'll 
> blog about this soon, but the short of it is that I am very 
> grateful to Walter, Andrei, Kai, Ian, Johan and others for 
> creating a language that fits our needs so well! D software 
> is doing critical work around the world every second. D is 
> probably not a language for the hype community - let them 
> have Go and Rust. I honestly don't care. And D should not 
> care. Great programmers gyrate to powerful languages and 
> toolboxes. I love I can read the source code of Phobos and 
> understand it. I love I get low level access to stack 
> variables. I love I can manipulate the heap in any way I 
> want. I love we can target GPU and KNL. I love we have Maybe 
> even though it is called Nullable...
> 
> A great programmer can handle D fine. As it is. Let's not 
> try to be the next hype. Let's keep writing great software.
> 
+1


+1 * 2


T


To clarify, I too like D. It is certainly very pleasant to work 
with. This post wasn't about GitHub issues vs Bugzilla. That was 
a get-off-at-a-tangent topic. This post is about what's needed 
for a more mature D; mature enough for extremely big companies to 
build bigger and more critical parts of their tech stacks in D 
(this *is* a huge investment)! The goal is never about making D a 
hype language.


I agree, a great programmer can handle anything, not just D as it 
is, but that's never an excuse to be complacent, it's never an 
excuse not aim for a higher quality in the D compiler and the 
infrastructure. Hope you understand.


Thanks.

Re: What do you want to see for a mature DLang?

[IM via Digitalmars-d]

On Sunday, 31 December 2017 at 21:16:35 UTC, Walter Bright wrote:

On 12/31/2017 8:18 AM, IM wrote:

What do you think? Do you agree that a process is needed?


We've tried adding process before. It does not work, for the 
simple reason that it requires a dedicated group of people to 
dedicate time to it.


Something should work. It just needs to be found. People are 
already dedicating time to D by contributing fixes and filing 
issues, responding on the forums, ... etc. Organizing work and 
priorities is not an exception. It doesn't take that long by the 
way, only 30 ~ 60 minutes per week max should be more than 
enough. I hope you could take the upcoming DConf as an 
opportunity to discuss with others ways to enhance the process 
and minimize friction.




Are you willing to do that?



I'd be happy to do it, but I'm not the right person for it. This 
needs someone who knows D very well, knows the bigger picture, 
and is familiar with the contributors and who mostly works on 
what to be able to adjust priorities and ownership appropriately. 
I've been learning and experimenting with D only for a few 
months. Also, I'm worried about - though unlikely - to put myself 
in a conflict-of-interest situation; we don't use D at work, and 
as far as I know there are neither interest nor plans to do so. I 
hope this will change one day, and that's why I started this 
post, because quality and maturity are very important.


We have added process when someone has stepped up to do the 
thankless job of administering it.


I think it is thankful and as important as submitting PRs and 
DIPs. Shaping, organizing, and directing human effort are just as 
important as the human effort itself.

Re: What do you want to see for a mature DLang?

[IM via Digitalmars-d]

On Sunday, 31 December 2017 at 07:43:35 UTC, Walter Bright wrote:

On 12/30/2017 11:23 PM, IM wrote:
While we are discussing it here, could you please let me know 
what the bug triage process for each release cycle is? Is it 
random that anyone picks up whatever bug s/he feels like 
fixing? Or is it that if contributors will contribute X number 
of patches this cycle, then there is some sort of guidance and 
direction of this effort towards fixing some high priority 
bugs?


Bugs are ranked by severity, but generally what gets fixed are 
bugs that a particular person self-selects an interest in 
fixing it.


Often people who just want to help out will peruse the buglist 
looking for issues that match their skill levels that they can 
fix.


I hope that you could see that this doesn't scale very well, and 
some kind of a process needs to be established to shape and 
direct the efforts. Some thoughts/suggestions:
- Weekly meeting to review open bugs, adjust their components and 
priority appropriately, and assign to potential owners (those who 
can or likely to fix the bugs. Owners can then reassign or 
unassign if not interested).
- Maybe ask someone to volunteer for triaging bugs in each 
component. So every component has an owner.
- If a bug has been assigned to someone and hasn't received any 
attention (i.e. remained open for say 3 months), a bot should 
unassign it so that it returns back to the triage pool, hoping 
that it will catch the attention of the triage volunteers.


What do you think? Do you agree that a process is needed?

Re: What do you want to see for a mature DLang?

[IM via Digitalmars-d]

On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:

On 12/30/2017 6:42 AM, Muld wrote:
In contrast this same problem exists for Bugzilla. You say 
it's working cause it's better than using notepad or some 
other stupid shit. Bugzilla isn't the issue, it's the fact the 
people maintaining it aren't willing to commit to anything and 
leave issues open that shouldn't be left open. That just 
results in noise making it difficult to see what actual issues 
are. I'm not even talking about duplicate entries as you seem 
to have have misunderstood.


Anyone can contribute to bugzilla with reasoned advice about 
what to do with various issues, and can review PRs. The people 
responsible are, well, anyone who wants to be.


Please join and help out.


While we are discussing it here, could you please let me know 
what the bug triage process for each release cycle is? Is it 
random that anyone picks up whatever bug s/he feels like fixing? 
Or is it that if contributors will contribute X number of patches 
this cycle, then there is some sort of guidance and direction of 
this effort towards fixing some high priority bugs?

Re: What do you want to see for a mature DLang?

[IM via Digitalmars-d]

On Friday, 29 December 2017 at 17:29:47 UTC, Adam D. Ruppe wrote:

On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
   -- Better compiler errors, better compiler errors, better 
compiler errors.



This is the only thing I greatly care about anymore. Biggest 
problem D has in real world use.


Please allow me to give an example of how first impressions of 
maturity really matter! Recently at some company, a group of 
engineers started advocating for using Rust. They wrote a doc 
explaining the differences and benefits of Rust over C++ (which 
is heavily used). People started experimenting, and immediately 
the maturity and good user experience of rustc and cargo were 
quite obvious. The result was that Rust is now more appealing, 
some new projects were written in Rust, some old ones have or are 
being migrated from C++ to Rust.


(**This is a real story by the way**)

Now, given the fact that I love D despite some of the annoying 
issues I encounter with it frequently, I would like to call my 
colleagues to give it a try and experiment with it. People start 
getting interested. They start writing some code, and eventually 
they hit one of those unhelpful compile error messages, which 
could indicate one of the following:
- An error in the engineer's knowledge of the language which the 
compiler didn't help to understand what it is so that s/he goes 
to look it up.

- A bug in Phobos.
- An actual compiler bug or inconsistency.

Remember, those engineers are experimenting with D to use it for 
serious projects at work, not personal toy projects. What do you 
think? Is it likely that they decide to invest a lot of time and 
resources migrating projects to D?


Maturity (or at least approaching it as much as possible) is VERY 
VERY VERY important.


I like what the D foundation did to the website, the language and 
library docs, the Learn section, the forums, the resources ... 
etc. That definitely gives the impression of maturity.


Looking forward to seeing more of that in the compiler, which is 
the single most important thing in a programming language, the 
reason it exists, the thing I interface with most of the time.

Re: What do you want to see for a mature DLang?

[IM via Digitalmars-d]

On Saturday, 30 December 2017 at 01:40:39 UTC, Adam D. Ruppe 
wrote:
On Friday, 29 December 2017 at 23:24:45 UTC, Walter Bright 
wrote:

That's been closed for a while now.


Well, take your pick:

https://issues.dlang.org/show_bug.cgi?id=12694
https://issues.dlang.org/show_bug.cgi?id=13340
https://issues.dlang.org/show_bug.cgi?id=16059

You always tell people to post to bugzilla, but many of these 
things have been posted over and over again. Bugzilla search is 
terrible, so it is frequently hard to find, but there are many 
examples there.


The benefit though of watching support requests is you see what 
people actually deal with day-to-day, and error messages, 
especially multiple overload matches of functions and templates 
and no template matches ones come up all the time. ALL THE 
TIME. From new users and experienced users alike. Most won't 
put it in bugzilla though: they just see it as their own 
personal failure instead of a technical problem we can fix.


But any repeated support request should be seen as a user 
experience problem that we try to fix. This is where we'd get 
the most productivity - taking little bumps out of the road. D 
has no roadblocks; we can get a lot of stuff done with it 
exactly the way it is, but if you watch users actually try to 
use it, you'll see the road isn't as smooth as it could and 
should be.


Just curious, why Bugzilla and not something else? I can guess 
the following:
- A centralized place for all dmd, druntime, and phobos was 
needed.
- GitHub issues are probably more limited in features and 
functionality than Bugzilla.


But think about it. Filing a bug on Bugzilla is not 
friction-free. One has to create an account, if s/he has one 
already, good luck remembering the username and password for 
something you rarely use, so spend sometime trying to remember 
and when you fail, spend time resetting your account or creating 
a new one. Finally file a bug and pray that someone will actually 
notice it and triage it to the appropriate owner! Not to mention 
that Bugzilla's UI is not pleasant.


For GitHub issues, most probably you already have an account 
there that you use often. Issues are close to where the code is. 
It's easy to see potential owners from the code's blame or git 
log. .. etc.


For better community participation, friction needs to be 
minimized as much as possible.

Re: Compiler bug?

[IM via Digitalmars-d]

On Friday, 29 December 2017 at 07:55:08 UTC, Daniel Kozak wrote:

But maybe you can propose cjange from ref R r to auto ref R r



If this will make it work with both lvalues and rvalues, then 
yes, this would be a nice fix. No need to force users to cache 
string line = readln(); first and then use it with 
formattedRead().



https://dlang.org/spec/template.html#auto-ref-parameters

On Fri, Dec 29, 2017 at 8:50 AM, Daniel Kozak 
 wrote:



No it is not a bug, because
 uint formattedRead(alias fmt, R, S...)(ref R r, auto ref S 
args)
could not match (there is a ref R r) so in your first example 
you dont

have lvalue but rvalue

What do you want to see for a mature DLang?

[IM via Digitalmars-d]

I will start:

   -- Better compiler errors, better compiler errors, better 
compiler errors.



I really wish that the compiler errors could receive some 
refinement. Mostly it feels like some error text just being 
thrown at me. It needs to be better formatted, more helpful, with 
suggestions about how to fix (if possible).


To illustrate my point:

- See the compile errors I've just encountered with DMD: 
https://cdn.pbrd.co/images/H0q609l.png


- Now compare that with an error produced by rustc:
https://cdn.pbrd.co/images/H0q6bLi.png


Simple things like these make a big difference. D Lang has been 
around for a long while now, and hence signs of its maturity has 
to show everywhere, especially in the compiler, as well as the 
package manager.

Compiler bug?

[IM via Digitalmars-d]

The following code:

  int guess;
  readln().formattedRead!"%d"(guess);

produces the following compiler error:

Error: template std.format.formattedRead cannot deduce function 
from argument types !("%s")(string, int), candidates are:
/usr/include/dmd/phobos/std/format.d(635):
std.format.formattedRead(alias fmt, R, S...)(ref R r, auto ref S 
args) if (isSomeString!(typeof(fmt)))
/usr/include/dmd/phobos/std/format.d(644):
std.format.formattedRead(R, Char, S...)(ref R r, const(Char)[] 
fmt, auto ref S args)


That is odd! I expected this to match:

  uint formattedRead(alias fmt, R, S...)(ref R r, auto ref S args)

However, the following works!!!

  int guess;
  string line = readln();
  line.formattedRead!"%d"(guess);


This definitely looks like a bug, but I want to confirm first 
before filing one.

Compiler gets confused with ambiguity when `int` matches both `real` and `float`.

[IM via Digitalmars-d-learn]

The following expression:

import std.math : sqrt;
sqrt(400);

produces the following compiler error:

std.math.sqrt called with argument types (int) matches both:
/usr/include/dmd/phobos/std/math.d(1592,7): 
std.math.sqrt(float x)

and:
/usr/include/dmd/phobos/std/math.d(1598,6): 
std.math.sqrt(real x)


Shouldn't it just pick one according to some defined rules?

Re: Is it possible to request a code review?

[IM via Digitalmars-d]

On Friday, 15 December 2017 at 21:34:48 UTC, Neia Neutuladh wrote:

On Wednesday, 13 December 2017 at 03:15:11 UTC, IM wrote:

https://code.dlang.org/packages/libdtasks


I'd get rid of the ITaskRunner interface and rename 
AbstractTaskRunner to TaskRunner. Interfaces are fine when you 
need them, but you rarely need them. You can just make 
PostTaskAndReply non-final and it's the same. It's slightly 
cheaper than calling the final method through an interface, 
even.




That's a fair point. Thanks.

I'd also eliminate TaskSystem. You can use a thread-local 
TaskRunner pretty much the same way, and it's a bit weird to 
have policy based on thread ID. (Normally, you would have a 
threadpool-like thing for each type of task. Like one for 
serving web traffic, one for transcoding video, one for reading 
RSS feeds, etc.) Thread IDs can be reused, so if you forget to 
clean something up, you might end up reusing the wrong 
TaskRunner later. A thread-local variable also reduces the work 
you have to do to stop a thread.


In any case, the TaskRunner-per-thread thing is a policy 
decision that's not really appropriate for a library to make. 
You generally try to leave that to applications.




Applications can instantiate multiple single thread task runners, 
each for a specific type of tasks as you mentioned earlier. They 
can also instantiate a thread pool task runners for tasks that 
are independent, don't need to run sequentially or any order, or 
on any particular thread.



TaskQueue has a race condition, I think:


Thread 1 calls Pop(). It acquires the mutex.
Thread 1 observes there are no tasks available to pop. It 
waits on the condition variable.
Thread 2 calls Push(). It tries to acquire the mutex, but the 
mutex is taken. It blocks forever.




That's not true. Waiting on a condition variable should unlocked 
the mutex first, the put the thread to sleep. That's how most 
implementations are. See for example: 
http://en.cppreference.com/w/cpp/thread/condition_variable/wait


Reading code is generally easier when that code follows the 
style guide for the language. https://dlang.org/dstyle.html and 
maybe run dfmt on your code. For instance, when you write 
`atomicOp !"+="`, it takes me about a full second to connect 
that to the common style of `atomicOp!"+="`. If I worked with 
your code for an hour, that would go away, but it's a bit of a 
speedbump for new contributors.




Yeah, if you noticed, I use clang-format rather than dfmt. I 
found dfmt to be very buggy, especially when using 80-character 
line limit. It also produces formatted code that I don't like, 
especially when there's multiple indentations. clang-format 
doesn't support D unfortunately, so I have to add '// 
clang-format off .. on' here and there. It is clang-format that 
added that extra space after 'atomicOp!'. I wish it has full 
support for D like it does for Java and Javascript, but hey it 
mostly works, so fine.


One other point of note about formatting: I never regret using 
braces around single-statement blocks. Like:


while (!done && tasks.length == 0)
{
condition.wait;
}

I just so frequently need to add logging or extra bookkeeping 
to statements like that that it's not even worth the time to 
try to omit braces.


I believe less braces and less indentation is better. I like to 
keep the code minimal with minimal whitespace around it, but 
that's just my personal pereferance.


Thank you very much for your review.

Re: Is it possible to request a code review?

[IM via Digitalmars-d]

I'm still looking for feedback about these points:

  - Any candidate class that can be better switched to a struct 
or even a template?
  - The use of shared and __gshared, did I get those right? I 
find the TLS concept unpleasant, because it makes me unsure 
what's the right thing to do. For example:
- If a class that instances of which will be accessed by 
multiple threads, should it be marked `shared`. For instance 
`TaskQueue` 
(https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/TaskQueue.d#L9).
- What about the members of a class, do they ever need to be 
marked as shared?
- Also, in this unittest : 
https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/SingleThreadTaskRunner.d#L148, I didn't mark `number` as shared, even though it is accessed by two threads, and I didn't see any unexpected behavior (because the task runners implicitly synchronize access to it using tasks and replies). But in the other unittest here: https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/ThreadPoolTaskRunner.d#L100, I marked `number` as shared just because I believed I have to since it will be accessed by many threads arbitrarily.

Re: Is it possible to request a code review?

[IM via Digitalmars-d]

On Thursday, 14 December 2017 at 12:51:07 UTC, rjframe wrote:

On Wed, 13 Dec 2017 03:15:11 +, IM wrote:


[...]


I like this API design.


I would separate each unit test to its own `unittest` block 
(you have three tests in a single block in 
`SingleThreadTaskRunner.d`); it doesn't really matter with the 
integrated runner, but if you later use a runner like 
unit-threaded[1] or tested[2] each unit test block becomes its 
own independent test, and they will all be run, even if one or 
more fails.




Interesting. I haven't decided which tester runner to use yet, 
because the built in one is minimal and is getting me going. But 
thanks for the pointers. `tested` seems interesting because it's 
minimal and I like minimal things, however it seems it hasn't 
been touched for 2 years.




If `TaskQueue.Pop` returned the Task rather than used an out 
parameter,

this (in SingleThreadTaskRunner.RunnerLoop):
```
while (true) {
  Task front;
  mQueue.Pop(front);
  if (!front)
return;

  front();
}
```
could become:
```
while (true) {
auto front = mQueue.Pop();
front ? front() : return;
}

```
Though that's probably debatable as to which is more readable. 
I would
avoid `out` parameters on void functions; I would at least 
return a `bool`

and test that instead (which is what `TryPop` does):
```
while (true) {
Task front;
if (!mQueue.Pop(front)) {
return;
}
front();
```

I would probably switch the if block to the affirmative case, 
but that's personal preference.




I like that. I wouldn't switch it to affirmative because I like 
the early return and not having to add an `else`.


`Pop` could call `TryPop` to eliminate code duplication. The 
same is true for other Try functions.



I'll ignore the style since others have discussed it and it's 
not what you're looking for, but this does look like C#. Style 
actually is somewhat- important; if I use your library in a 
project, it would be nice if API calls look like they belong in 
my code. That's why everybody recommends at least following the 
Phobos naming guidelines for published libraries.




That's a fair point, and I agree. I will consider switching to 
the Phobos

guidelines at some point.

I only skimmed other reviews, so this may have been mentioned; 
in `TaskQueue.d`, a private function is misspelled: 
"AppednTaskThreadUnsafe" -> "AppendTaskThreadUnsafe".




Oops, thanks!


--Ryan


[1]: http://code.dlang.org/packages/unit-threaded
[2]: http://code.dlang.org/packages/tested

Re: Is it possible to request a code review?

[IM via Digitalmars-d]

On Thursday, 14 December 2017 at 07:47:58 UTC, Ali Çehreli wrote:

On 12/13/2017 07:57 PM, IM wrote:

>  - Is this the idiomatic way to define a singleton in D?:
> 
https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/TaskSystem.d#L24.


> I got this from Ali's book.

I think you got it from Adam D. Ruppe's book.



Ooops, sorry, I thought I got it from your book because I've been 
reading in it recently. But no, I didn't get it from Adam D. 
Ruppe's book. Turned out that I actually got it from the 
initOnce() example in the docs here: 
https://dlang.org/library/std/concurrency/init_once.html


David Simcha's DConf 2013 presentation has Low-Lock Singleton 
Pattern at 28 minute mark here:


  
https://www.youtube.com/watch?v=yMNMV9JlkcQ=youtu.be=1675


Ali


Thanks for the pointer. I'll check it out!

Re: Is it possible to request a code review?

[IM via Digitalmars-d]

On Thursday, 14 December 2017 at 04:12:33 UTC, rikki cattermole 
wrote:

On 14/12/2017 3:57 AM, IM wrote:

snip

     - Is this the idiomatic way to define a singleton in D?: 
https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/TaskSystem.d#L24.


You say singleton I think wrong.

Use free-functions and globals instead.

Singletons are always a code smell that OOP based languages 
like to say are a 'good thing'.


e.g.

module taskmgr;
import task;

private __gshared {
Task[] tasks;
}

Task[] getTasks() {
return tasks;
}

void clearTasks() {
tasks = null;
}

void addTask(Task t) {
tasks ~= t;
}


Sure, that works too, Thanks. However, we could leave the debate 
about the pros and cons of singletons for another day. That's not 
what my question was about though.

Re: Is it possible to request a code review?

[IM via Digitalmars-d]

On Wednesday, 13 December 2017 at 07:30:55 UTC, Jonathan M Davis 
wrote:
On Wednesday, December 13, 2017 06:14:04 bauss via 
Digitalmars-d wrote:

Documentation can be done like this for multiline:

/**
* ...
* ...
* etc.
*/

Instead of:

/// ...
/// ...
/// etc.


You can also do

/**
  ...
  ...
  etc.
*/

or

/++
  ...
  ...
  etc.
+/

Personally, I always use the last one if the ddoc comment is 
multiple lines, and I've never understood why anyone would want 
all those extra *'s on the side.


- Jonathan M Davis


I think it is believed that the extra stars:

/**
 * 
 * 
 */

make the docs stand out and look better (as if they're inside a 
blockquote or something).


However, doc styles and code style in general is not my primary 
concern right now. I want dive deeply into D first, and worry 
about style later.

Re: Is it possible to request a code review?

[IM via Digitalmars-d]

On Wednesday, 13 December 2017 at 07:02:47 UTC, Ali Çehreli wrote:

On 12/12/2017 07:15 PM, IM wrote:

I started learning D recently.


Welcome! There is also the Learn newsgroup[1]. ;)

Ali

[1] Available through a forum interface here:

  http://forum.dlang.org/group/learn


Thanks, I posted a question there once already.

Re: Is it possible to request a code review?

[IM via Digitalmars-d]

On Wednesday, 13 December 2017 at 06:14:04 UTC, bauss wrote:

On Wednesday, 13 December 2017 at 03:15:11 UTC, IM wrote:

Thanks!


First thing.

Generally in D module names are kept lower-case.

To give an example your:
AbstractTaskRunner.d
module tasks.AbstractTaskRunner;

Would usually be:
abstracttaskrunner.d
module tasks.abstracttaskrunner;

Of course it's not necessary, but it's how it usually is in 
idiomatic D.


The same goes for function names etc. they're usually kept 
camelCase and not PascalCase like you have it. Again it's not 
necessary, but that's idiomatic D.


A wild guess from me would be that you come from a C#/.NET 
background OR you have worked heavily with the win api, am I 
right?




No, I'm coming from a C++ background. Though I did a bit of C# 
long time ago.



Documentation can be done like this for multiline:

/**
* ...
* ...
* etc.
*/

Instead of:

/// ...
/// ...
/// etc.

This might just be a personal thing for me, but I always use 
/// for single-line documentation only.


Also you don't need to define constructors for classes, if they 
don't actually do something.


Ex. your SingleThreadTaskRunner class defines this:

~this() @safe {}

Integers are automatically initialized to int.init which is 0, 
so the following is can be rewritten from: (Find in a unittest)


int value = 0;

to:

int value;


I feel like it doesn't hurt to be explicit about it, but I get 
your point.




Also empty lambdas like:

() { ... }

can be written like:

{ ... }


That's actually better, thanks!



Also you have a few Hungarian notations, which is often not 
used in idiomatic D.


The key for an associative array __should__ always be treated 
const internally, so this:


ITaskRunner[const Tid]

shouldn't be necessary and doing:

ITaskRunner[Tid] should work just fine.

If you have experienced otherwise, then I'd argue it's a bug 
and you should report it.


I think I made it so, because I had a function with signature:

void Foo(const Tid tid) {
  // Use `tid` to access the associative array, which refused
  // to compile unless the key was marked `const` in the 
declaration.

}



Also statements like this:

immutable int currentNumber

are often preferred written like:

immutable(int) currentNumber

And getting too used to write:

immutable int currentNumber

might have you end up writing something like:

immutable int getAnImmutableNumber() { ... }

Which does not do what you would expect as it doesn't treat the 
return value as immutable, but instead "this" as immutable.


To make the return type immutable you'd write:

immutable(int) getAnImmutableNumber() { ... }

I don't know if you know that already, but just figured I'd 
give a heads up about that.


No, I didn't know. Thanks for mentioning!



That was all I could see looking through your code real quick.

Take it with a grain of salt as some of the things might be 
biased.


Thanks. That was definitely helpful.

I was also looking for more feedback about the following:

  - Any candidate class that can be better switched to a struct 
or even a template?
  - The use of shared and __gshared, did I get those right? I 
find the TLS concept unpleasant, because it makes me unsure 
what's the right thing to do. For example:
- If a class that instances of which will be accessed by 
multiple threads, should it be marked `shared`. For instance 
`TaskQueue` 
(https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/TaskQueue.d#L9).
- What about the members of a class, do they ever need to be 
marked as shared?
- Also, in this unittest : 
https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/SingleThreadTaskRunner.d#L148, I didn't mark `number` as shared, even though it is accessed by two threads, and I didn't see any unexpected behavior (because the task runners implicitly synchronize access to it using tasks and replies). But in the other unittest here: https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/ThreadPoolTaskRunner.d#L100, I marked `number` as shared just because I believed I have to since it will be accessed by many threads arbitrarily.
- Is this the idiomatic way to define a singleton in D?: 
https://gitlab.com/3d_immortal/libdtasks/blob/master/src/tasks/TaskSystem.d#L24. I got this from Ali's book.


Thank you!

Is it possible to request a code review?

[IM via Digitalmars-d]

I started learning D recently. As part of the learning process, I 
started working on some D projects to experiment and learn. My 
first project is a tasking system library that I plan to use in 
another D project I'm working on.


The goal is to be able to post and run any task asynchronously on 
current thread, new thread, or thread pool, and possibly getting 
a callback on the posting thread when the task has run to 
completion. I will probably expand it more as I go. I've just 
published it on DUB here: 
https://code.dlang.org/packages/libdtasks


Being new to D, I probably made many mistakes, or did things in a 
way where there's a more optimum one to do in D. I'm eager to 
know how to improve, and would like to know if there is any 
experienced D developer who is thankfully willing to take a look 
at it and give me feedback?


Thanks!

Re: Invoking writeln() from a lot of threads running concurrently --> crash

[IM via Digitalmars-d]

On Saturday, 9 December 2017 at 10:36:08 UTC, Messenger wrote:

On Saturday, 9 December 2017 at 09:38:05 UTC, IM wrote:
For purposes of debugging, I'm using writeln() to print stuff 
out from tasks running concurrently on many threads. At some 
point it crashes with the following stack trace:


Thread 4 received signal SIGUSR1, User defined signal 1.

[...]

Bug in phobos?


Is that a crash or just thread 4 receiving SIGUSR1? (GC signal)

If so you just need to tell gdb not to stop on that. ("handle 
SIGUR1 SIGUSR2 nostop", place it in ~/.gdbinit)


Thanks! That works!

Re: Invoking writeln() from a lot of threads running concurrently --> crash

[IM via Digitalmars-d]

On Sunday, 10 December 2017 at 01:12:37 UTC, Walter Bright wrote:

On 12/9/2017 5:56 AM, Seb wrote:

IIRC the implementation of LockingTextWriter isn't thread-safe.


There's no bugzilla issue on this. So I added one:

  https://issues.dlang.org/show_bug.cgi?id=18052

Please, folks, I can't emphasize this enough. When you find a 
bug, POST IT ON BUGZILLA! Otherwise, it will NEVER get fixed.


I was going to file one, but I wanted to verify first that it's 
actually a bug. According to comment #2 by Messenger, it doesn't 
seem to be one if SIGUSR1 is a GC signal. I was trying to debug a 
crash in gdb and that one kept showing up. After adding handle 
SIGUSR1 SIGUSR2 nostop I was able to capture the real issue.


Sorry for the false positive --- still learning about D! :( I 
think we can probably close that bug.

Invoking writeln() from a lot of threads running concurrently --> crash

[IM via Digitalmars-d]

For purposes of debugging, I'm using writeln() to print stuff out 
from tasks running concurrently on many threads. At some point it 
crashes with the following stack trace:


Thread 4 received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x75ec2700 (LWP 19267)]
__lll_lock_wait_private () at 
../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95	../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file 
or directory.

(gdb) bt
#0  __lll_lock_wait_private () at 
../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x77bcb2d5 in __flockfile (stream=0x7728b780 
<_IO_stdfile_1_lock>) at ../sysdeps/pthread/flockfile.c:28
#2  0x0045f5b0 in 
_D3std5stdio4File17LockingTextWriter6__ctorMFNcNeKSQBxQBwQBtZSQCiQChQCeQCc ()
#3  0x0045f670 in 
_D3std5stdio4File17lockingTextWriterMFNfZSQBoQBnQBk17LockingTextWriter ()
#4  0x0044a1e0 in 
_D3std5stdio4File__T5writeTAyaTyiTaZQqMFNfQpyiaZv (this=..., 
_param_2=10 '\n', _param_1=12, _param_0=...)

at /usr/include/dmd/phobos/std/stdio.d:1399

Note that I didn't add any synchronizations around the writeln() 
calls, should I? I assume the implementation *should* synchronize 
access to std_out, no?


Bug in phobos?

Re: Abstract Classes

[IM via Digitalmars-d-learn]

On Wednesday, 6 December 2017 at 23:16:54 UTC, Ali Çehreli wrote:

On 12/06/2017 03:01 PM, IM wrote:
> On Wednesday, 6 December 2017 at 07:54:21 UTC, Ali Çehreli
wrote:
>> On 12/05/2017 11:23 PM, IM wrote:
>>> [...]
>>
>> Just remove the override keywords in this case. No function
is
>> overriding any implementation here, they both implement an
interface
>> function. The fact that override can be used for A.foo can
be seen as
>> an inconsistency or a bug.
>>
>> Ali
>
> I believe this is a bug, and a confusing one to be honest.
Can you
> please help file one against the right owners? Thanks!

There is no owners field when opening an issue. To get you 
started on the bug tracking system, please create this one 
yourself: :)


  https://issues.dlang.org/

Thank you,
Ali


Done: https://issues.dlang.org/show_bug.cgi?id=18041. Thanks!

Re: Abstract Classes

[IM via Digitalmars-d-learn]

On Wednesday, 6 December 2017 at 07:54:21 UTC, Ali Çehreli wrote:

On 12/05/2017 11:23 PM, IM wrote:

[...]


Just remove the override keywords in this case. No function is 
overriding any implementation here, they both implement an 
interface function. The fact that override can be used for 
A.foo can be seen as an inconsistency or a bug.


Ali


I believe this is a bug, and a confusing one to be honest. Can 
you please help file one against the right owners? Thanks!

Abstract Classes

[IM via Digitalmars-d-learn]

Assume the following:

interface IFace {
  void foo();
  void bar();
}

abstract class A : IFace {
  override void foo() {}
}

class B : A {
  override void bar() {}
}

Now why this fails to compiler with the following message:


--->>>
function bar does not override any function, did you mean to 
override 'IFace.bar()'?

<<<---


Obviously, I meant that, since the abstract class A implements 
IFace, and B derives from A.


Do I need to declare IFace's unimplemented methods in A as 
abstract? If yes, why? Isn't that already obvious enough (any 
unimplemented virtual function is abstract)?

Re: Thoughts about D

[IM via Digitalmars-d]

On Monday, 27 November 2017 at 08:33:42 UTC, IM wrote:
- More exposure. I sometimes feel like there isn't enough D 
material to consume on a regular basis (and I and certainly 
many others are eager to learn more and more about the 
language). i.e. one blog post (weekly?), and a single DConf 
annually is not enough. In the C++ world, there's always 
something to read (various blog posts) or something to watch 
(CppCon, C++Now, Meeting C++, code::dive, Pacific++, ...etc.)




What are the plans to increase exposure?

Re: Thoughts about D

[IM via Digitalmars-d]

On Monday, 27 November 2017 at 02:56:34 UTC, Walter Bright wrote:

On 11/26/2017 4:14 PM, IM wrote:
I'm a full-time C++ software engineer in Silicon Valley. I've 
been learning D and using it in a couple of personal side 
projects for a few months now.


Great! Glad you're enjoying it and took the time to post your 
thoughts.



- D is unnecessarily a huge language. I remember in DConf 
2014, Scott Meyers gave a talk about the last thing D needs, 
which is a guy like him writing a lot of books covering the 
many subtleties of the language. However, it seems that the D 
community went ahead and created exactly this language!


You'll find the same language in 2014 as today, it hasn't 
changed much. All languages (except C) in common use accrete 
features.


D does have some baggage that has been removed, like `typedef`, 
but on the whole whenever we try to remove something, someone 
always has built their store around it.


The good news, however, is just use the subset of D that works 
for you.



- ‎D is very verbose. It requires a lot of typing. Look at how 
long 'immutable' is. Very often that I find myself tagging my 
methods with something like 'final override nothrow @safe 
@nogc ...' etc.


The idea is if you just want to write code, you can eschew 
using them (except 'override'), and just write code. They're 
all used for optimization or to provide enforceable 
self-documentation. Other languages would require those to be 
documented in the comments, which is not enforceable and even 
more wordy :-)


'override' is as opposed to 'virtual' which C++ requires and D 
doesn't.



- ‎It's quite clear that D was influenced a lot by Java at 
some point, which led to borrowing (copying?) a lot of Java 
features that may not appeal to everyone.


That's true. Java looked like it was going to take over the 
world when D was young. These days I'd get rid of inner classes 
in favor of lambdas if I could, but you can just ignore inner 
classes.



- ‎The amount of trickeries required to avoid the GC and do 
manual memory management are not pleasant and counter 
productive. I feel they defeat any productivity gains the 
language was supposed to offer.


That's true. But it's hard to beat GC for just writing code and 
getting it to run safely and without pointer bugs.



- ‎The thread local storage, shared, and __gshared business is 
annoying and doesn't seem to be well documented, even though 
it is unnatural to think about (at least coming from other 
languages).


The idea with TLS is to deal with endemic threading bugs other 
languages have. The default in C/C++ is for globals to be 
shared, which is completely impractical to examine a large code 
base for. __gshared is meant to stand out and be greppable, 
making code much more auditable.



- ‎D claims to be a language for productivity, but it slows 
down anyone thinking about efficiency, performance, and 
careful design decisions. (choosing structs vs classes, 
structs don't support hierarchy, use alias this, structs don't 
allow default constructors {inconsistent - very annoying}, 
avoiding the GC, look up that type to see if it's a struct or 
a class to decide how you may use it ... etc. etc.).


D structs are value types, and classes are reference types. 
Everything flows from that. C++ structs and classes are the 
same thing, and can be used as both reference and value types 
at the same time, whether that works or not. I rarely find C++ 
classes with documentation saying if they are intended as a 
reference or value type, and the documentation won't prevent 
one from misusing it.


I'm not the only one to suggest that making the value/ref 
design decision is a pretty crucial one to make before 
designing the code. :-)



I could add more, but I'm tired of typing. I hope that one day 
I will overcome my frustrations as well as D becomes a better 
language that enables me to do what I want easily without 
standing in my way.


Many people have difficulty with D when coming from, say, C++, 
because it does require a different way of thinking about code. 
This passes once one gains experience and comfort with D. After 
all, my early Fortran code looked just like BASIC, my C code 
looked like Fortran, my C++ code looked like "C with a few 
classes", and my D code looked a bit too much like C++ :-)


I have recently finished converting the Digital Mars C++ 
compiler front end from "C with classes" to D. Even though it 
is a rote line-by-line translation, it simply looks better in D 
(much less of a snarl). Over time, as I refactor bits of it, 
it'll steadily look better. I find it significantly easier to 
write good looking code in D, and it is less verbose than C++.


For some trivial examples,

C++: unsigned long long
D: ulong

C++: template struct S { ... };
D: struct S(T) { ... }

C++: for (int i = 0; i < 10; ++i)
D: foreach (i; 0..10)

C++: decltype
D: auto


Thank you Walter, and all for your replies.

I want to 

Re: Thoughts about D

[IM via Digitalmars-d]

On Monday, 27 November 2017 at 05:11:06 UTC, Neia Neutuladh wrote:

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
- ‎It's quite clear that D was influenced a lot by Java at 
some point, which led to borrowing (copying?) a lot of Java 
features that may not appeal to everyone.


Have you observed a human to exist who has complained about a 
specific feature in D that is similar to a feature in Java? 
Relaying their complaints would be much more useful.




Yes, in particular All classes inherit from `Object`, virtual 
methods by default, inner classes pointers to parent classes ... 
to name a few.

Re: Thoughts about D

[IM via Digitalmars-d]

On Monday, 27 November 2017 at 03:01:24 UTC, Jon Degenhardt wrote:
Forum discussions are valuable venue. Since you are in Silicon 
Valley, you might also consider attending one of the Silicon 
Valley D meetups 
(https://www.meetup.com/D-Lang-Silicon-Valley). It's hard to 
beat face-to-face conversations with other developers to get a 
variety of perspectives. The ultimate would be DConf, if you 
can manage to attend.


Thanks. I intend to attend some of their meetup events.

Thoughts about D

[IM via Digitalmars-d]

Hi,
I'm a full-time C++ software engineer in Silicon Valley. I've 
been learning D and using it in a couple of personal side 
projects for a few months now.


First of all, I must start by saying that I like D, and wish to 
use it everyday. I'm even considering to donate to the D 
foundation. However, some of D features and design decisions 
frustrates me a lot, and sometimes urges me to look for an 
alternative. I'm here not to criticize, but to channel my 
frustrations to whom it may concern. I want D to become better 
and more widely used. I'm sure many others might share with me 
some of the following points:
- D is unnecessarily a huge language. I remember in DConf 2014, 
Scott Meyers gave a talk about the last thing D needs, which is a 
guy like him writing a lot of books covering the many subtleties 
of the language. However, it seems that the D community went 
ahead and created exactly this language!
- ‎D is very verbose. It requires a lot of typing. Look at how 
long 'immutable' is. Very often that I find myself tagging my 
methods with something like 'final override nothrow @safe @nogc 
...' etc.
- ‎It's quite clear that D was influenced a lot by Java at some 
point, which led to borrowing (copying?) a lot of Java features 
that may not appeal to everyone.
- ‎The amount of trickeries required to avoid the GC and do 
manual memory management are not pleasant and counter productive. 
I feel they defeat any productivity gains the language was 
supposed to offer.
- ‎The thread local storage, shared, and __gshared business is 
annoying and doesn't seem to be well documented, even though it 
is unnatural to think about (at least coming from other 
languages).
- ‎D claims to be a language for productivity, but it slows down 
anyone thinking about efficiency, performance, and careful design 
decisions. (choosing structs vs classes, structs don't support 
hierarchy, use alias this, structs don't allow default 
constructors {inconsistent - very annoying}, avoiding the GC, 
look up that type to see if it's a struct or a class to decide 
how you may use it ... etc. etc.).


I could add more, but I'm tired of typing. I hope that one day I 
will overcome my frustrations as well as D becomes a better 
language that enables me to do what I want easily without 
standing in my way.