Re: Two questions
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
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
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
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
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
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
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?
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?
I can't wait to watch.
Re: Official Dub package for DWT
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
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
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?
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?
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?
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?
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?
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?
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 Kozakwrote: 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?
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?
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`.
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?
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?
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?
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?
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?
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?
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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.