Re: LDC 1.13.0-beta1
On Tuesday, 6 November 2018 at 21:42:42 UTC, kinke wrote: On Tuesday, 6 November 2018 at 21:25:53 UTC, kinke wrote: We don't use any MinGW functions at all Let me rephrase that: the new MinGW-w64-based libs don't *include* any MinGW functions at all, not a single one. So you cannot use one by accident. ;) - For more in-depth infos, check out the linked PRs in the release log. Thanks for the details. A cursory read made it seem as if another C runtime was used: sorry for this.
Re: Backend nearly entirely converted to D
On 11/6/2018 3:00 PM, H. S. Teoh wrote: What sort of refactoring are we looking at? Any low-hanging fruit here that we non-compiler-experts can chip away at? Simply going with foreach loops is a nice improvement.
Re: Backend nearly entirely converted to D
On Tue, Nov 06, 2018 at 02:12:02PM -0800, Walter Bright via Digitalmars-d-announce wrote: > With the recent merging of the last of the big files machobj.d: > > https://github.com/dlang/dmd/pull/8911 > > I'm happy to say we're over the hump in converting the backend to D! > > Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c, > sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C > anyway - os.c and strtold.c. sizecheck.c will just go away upon > completion. > > Thanks to everyone who helped out with this! Awesome news! > Of course, the code remains as ugly as it was in C. It'll take time to > bit by bit refactor it into idiomatic D. What sort of refactoring are we looking at? Any low-hanging fruit here that we non-compiler-experts can chip away at? > The more immediate benefit is to get rid of all the parallel .h files, > which were a constant source of bugs when they didn't match the .d > versions. Finally! T -- Do not reason with the unreasonable; you lose by definition.
Backend nearly entirely converted to D
With the recent merging of the last of the big files machobj.d: https://github.com/dlang/dmd/pull/8911 I'm happy to say we're over the hump in converting the backend to D! Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c, sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C anyway - os.c and strtold.c. sizecheck.c will just go away upon completion. Thanks to everyone who helped out with this! Of course, the code remains as ugly as it was in C. It'll take time to bit by bit refactor it into idiomatic D. The more immediate benefit is to get rid of all the parallel .h files, which were a constant source of bugs when they didn't match the .d versions.
Re: Profiling DMD's Compilation Time with dmdprof
On Tue, Nov 06, 2018 at 07:44:41PM +, Atila Neves via Digitalmars-d-announce wrote: > On Tuesday, 6 November 2018 at 18:00:22 UTC, Vladimir Panteleev wrote: > > This is a tool + article I wrote in February, but never got around > > to finishing / publishing until today. > > > > https://blog.thecybershadow.net/2018/02/07/dmdprof/ > > > > Hopefully someone will find it useful. > > Awesome, great work! > > I really really hate waiting for the compiler. OTOH, I really really hate that the compiler, in the name of faster compilation, eats up all available RAM and gets OOM-killed on a low memory system, so no amount of waiting will get me an executable. T -- Famous last words: I wonder what will happen if I do *this*...
Re: LDC 1.13.0-beta1
On Tuesday, 6 November 2018 at 21:25:53 UTC, kinke wrote: We don't use any MinGW functions at all Let me rephrase that: the new MinGW-w64-based libs don't *include* any MinGW functions at all, not a single one. So you cannot use one by accident. ;) - For more in-depth infos, check out the linked PRs in the release log.
Re: LDC 1.13.0-beta1
On Tuesday, 6 November 2018 at 15:08:47 UTC, Guillaume Piolat wrote: On Monday, 5 November 2018 at 14:46:25 UTC, kinke wrote: On Monday, 5 November 2018 at 13:53:50 UTC, Guillaume Piolat wrote: Very cool! And very scary too, we'll have to verify the transcendantal precision and memcpy performance :) Don't worry, we're not using anything from the MinGW runtime itself - just functions exported by the MS DLLs and some minimal startup/shutdown skeleton (`mainCRTStartup` entrypoint etc.). We (incl. DMD) are just using their .def files as basis for the generated import libraries. I don't understand, llvm_exp for example translate to a call to the C stdlib exp() IIRC. That is currently in the MS runtime, no? Yep, and still is, as I said. We don't use any MinGW functions at all, so nothing changes in this regard, no need to worry about MinGW's 80-bit `long double`, their different C++ mangling, their .a static library format or their DWARF debug info. You're still targeting windows-msvc. We only need the MinGW .def files because Microsoft shamefully doesn't allow distribution of their static & import libs. As stated in the readme, using the MS toolchain is obviously still supported.
Re: The #dbugfix Campaign Round 1 Report
On Tuesday, 6 November 2018 at 11:15:09 UTC, RazvanN wrote: On Tuesday, 6 November 2018 at 11:12:44 UTC, Mike Parker wrote: [...] Sounds good. Thanks! Hi RazvanN, Any chance you could have a look at this one :) ? https://forum.dlang.org/post/zwxbdnxdvkbaesujw...@forum.dlang.org Kind regards Andre
Re: Lost in Translation: Encapsulation
On Tuesday, 6 November 2018 at 15:14:55 UTC, Mike Parker wrote: [...] I noticed that the `export` visibility attribute is curiously not mentioned anywhere in the article. I suppose it is not relevant to the encapsulation story, but it is weird to see it in the spec (https://dlang.org/spec/attribute.html#visibility_attributes) among public, private etc. but not the article.
Re: Profiling DMD's Compilation Time with dmdprof
On Tuesday, 6 November 2018 at 18:00:22 UTC, Vladimir Panteleev wrote: This is a tool + article I wrote in February, but never got around to finishing / publishing until today. https://blog.thecybershadow.net/2018/02/07/dmdprof/ Hopefully someone will find it useful. Awesome, great work! I really really hate waiting for the compiler.
Re: Profiling DMD's Compilation Time with dmdprof
On Tuesday, 6 November 2018 at 19:01:58 UTC, H. S. Teoh wrote: I don't have the time to look into this right now, but at a cursory glance, WOW. This is awesome! It looks like it would be really useful one day when I try to tackle the dmd-on-lowmem-system problem again. This will greatly help identify which Phobos modules cause big slowdowns on a low-memory host system. Great. Also, assuming that DMD still never deallocates, it should be pretty easy to turn this into a memory usage profiler by measuring the delta between the resident set size in samples.
Re: Profiling DMD's Compilation Time with dmdprof
On Tue, Nov 06, 2018 at 06:00:22PM +, Vladimir Panteleev via Digitalmars-d-announce wrote: > This is a tool + article I wrote in February, but never got around to > finishing / publishing until today. > > https://blog.thecybershadow.net/2018/02/07/dmdprof/ > > Hopefully someone will find it useful. I don't have the time to look into this right now, but at a cursory glance, WOW. This is awesome! It looks like it would be really useful one day when I try to tackle the dmd-on-lowmem-system problem again. This will greatly help identify which Phobos modules cause big slowdowns on a low-memory host system. T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Profiling DMD's Compilation Time with dmdprof
This is a tool + article I wrote in February, but never got around to finishing / publishing until today. https://blog.thecybershadow.net/2018/02/07/dmdprof/ Hopefully someone will find it useful.
Re: Lost in Translation: Encapsulation
On Tuesday, 6 November 2018 at 15:14:55 UTC, Mike Parker wrote: Last week, inspired by another discussion in these forums about D's private-to-the-module form of encapsulation, I spent a few hours putting a new article together for the blog. Ali, Joakim, Nicholas helped me get it in shape. The blog: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ Reddit: https://www.reddit.com/r/programming/comments/9up2yo/lost_in_translation_encapsulation_in_d/ You just describe how package access attribute works better then the spec itself! Good job. -Alex
Re: Lost in Translation: Encapsulation
On Tuesday, 6 November 2018 at 15:14:55 UTC, Mike Parker wrote: Last week, inspired by another discussion in these forums about D's private-to-the-module form of encapsulation, I spent a few hours putting a new article together for the blog. Ali, Joakim, Nicholas helped me get it in shape. The blog: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ Reddit: https://www.reddit.com/r/programming/comments/9up2yo/lost_in_translation_encapsulation_in_d/ Nicely done, think this could do well on proggit/HN/lobste.rs.
Blog post on fearless (library for @safe sharing)
https://www.reddit.com/r/programming/comments/9uoak1/implementing_rusts_stdsyncmutex_in_d/ Somewhere on hacker news too, but you know how that goes.
Re: Lost in Translation: Encapsulation
On 11/6/18 8:14 AM, Mike Parker wrote: Last week, inspired by another discussion in these forums about D's private-to-the-module form of encapsulation, I spent a few hours putting a new article together for the blog. Ali, Joakim, Nicholas helped me get it in shape. The blog: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ Reddit: https://www.reddit.com/r/programming/comments/9up2yo/lost_in_translation_encapsulation_in_d/ As usual, an excellent bit of writing containing things I wasn't aware of. Thanks!
Lost in Translation: Encapsulation
Last week, inspired by another discussion in these forums about D's private-to-the-module form of encapsulation, I spent a few hours putting a new article together for the blog. Ali, Joakim, Nicholas helped me get it in shape. The blog: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ Reddit: https://www.reddit.com/r/programming/comments/9up2yo/lost_in_translation_encapsulation_in_d/
Re: LDC 1.13.0-beta1
On Monday, 5 November 2018 at 14:46:25 UTC, kinke wrote: On Monday, 5 November 2018 at 13:53:50 UTC, Guillaume Piolat wrote: On Friday, 2 November 2018 at 21:04:13 UTC, kinke wrote: Glad to announce the first beta for LDC 1.13: * Based on D 2.083.0. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. Very cool! And very scary too, we'll have to verify the transcendantal precision and memcpy performance :) Don't worry, we're not using anything from the MinGW runtime itself - just functions exported by the MS DLLs and some minimal startup/shutdown skeleton (`mainCRTStartup` entrypoint etc.). We (incl. DMD) are just using their .def files as basis for the generated import libraries. I don't understand, llvm_exp for example translate to a call to the C stdlib exp() IIRC. That is currently in the MS runtime, no?
Re: LDC 1.13.0-beta1
On Saturday, 3 November 2018 at 16:33:36 UTC, kinke wrote: I figured it'd be for a lot of Windows users. Why not explicitly express your gratitude with a little 'thank you' then? After all, that little bullet point in the release notes easily took some 40 hours of my spare time, and some appreciation can work wonders to keep motivation up. Can send you some cryptocurrency if you want.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Monday, 5 November 2018 at 01:39:46 UTC, unprotected-entity wrote: On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote: On 11/2/2018 5:44 PM, Laeeth Isharc wrote: When one encounters a new idea that's unfamiliar sometimes it's easy to think that because it's unfamiliar it must be unsound. That can be a mistake. It might be better to suspend judgement for a while and keep an open mind. So true. My ideas on how to write code have changed dramatically over the years, and continue to change. I hear the advantages of the way D does it. But nobody wants to hear about the disadvantages. We heard you, we just disagree it's a disadvantage. What harm can come, from an optional tool, that enables enforceable encapsulation of a type, within a module (from code also in the module, but outside that type)? Can someone please answer that? The harm is complexity. But hey, if you want to write such a tool go right ahead. And yet again, I remind people that this is not a request for change. This is a discussion about what benefit such a tool can bring. In my opinion, no benefit at all.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Saturday, 3 November 2018 at 04:50:52 UTC, unprotected-entity wrote: On Saturday, 3 November 2018 at 00:44:15 UTC, Laeeth Isharc wrote: [...] I believe that responses like this, are really just designed to further obfuscate the point I'm trying to make, so that it cannot progress any further. Now, speaking of keeping an open mindlet's get back to my point.. can we? (q1) Why is it, that people who use D, object *so much* to the idea of allowing (at the choice of the programmer) for a type to have it's own private state *within* a module (so that its private state is respected by other code also within that module)? Because it adds no value. Creating a new file is not expensive. (q2)Why must a type within a module *always* have its private state exposed to other code within the module? (the key word here, being 'always'). Because then `friend` isn't needed. (q3) Should a language intentionally set out to prevent a programmer from making that choice? Yes, given that it decreases the overall complexity of the language.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Friday, 2 November 2018 at 10:18:11 UTC, ShadoLight wrote: On Friday, 2 November 2018 at 00:53:52 UTC, H. S. Teoh wrote: And along that line, recent wisdom is that it's better to move things *out* of classes (and structs) if they don't need access to private members. (Sorry, I wanted to include a link for this, but I couldn't find the article -- the title eludes me and google isn't turning up anything useful.) Class and struct APIs should be as minimal as possible -- just enough to do what needs to be done and no more, and the rest of the syntactic sugar (that makes it more palatable to your users) belongs outside as optional convenience functions. Maybe you are thinking of the "Prefer non-member non-friend functions to member functions" rule from Herb Sutter's "Effective C++" books? C++ however doesn't have reflection. The problem with non-member functions is I can't reflect on a type and loop over its member functions if some of the functionality is somewhere else.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote: On Thu, Nov 01, 2018 at 02:45:19AM +, unprotected-entity via Digitalmars-d-announce wrote: [...] Another thing to look for, is signs of code smell. I would include in this, unit tests calling private methods (which seems to be a popular thing for D programmers to do). Some will disagree that this is a code smell, but I have yet to see a good argument for why it is not. White-box testing. In principle, I agree with you that if your unittests are doing black-box testing, then they should definitely not be calling private methods. However, limiting yourself to black-box testing means your private functions can be arbitrarily complex If any of your functions are arbitrarily complex, you're doing it wrong (if alone) or your colleagues are (because it passed code review). and yet it's not thoroughly tested. If it's not thoroughly tested via the public API, then either some of the private code is useless and should be deleted, or the public API tests aren't good enough. Sometimes you really do want a unittest to ensure the private method is doing what you think it's doing, and this requires white-box testing. Only when writing the private method TDD-style. After it's written, I'd delete any and all tests for the private code and rely on the public API instead. Possibly useful when debugging though. This is especially important to prevent regressions, even if it seems redundant at first. Only doing black-box testing means a later code change in the private method can subtly introduce a bug that's not caught by the unittest (because it cannot call a private method directly to verify this). This makes no sense to me. If the public API tests didn't catch a regression, then the tests are bad. End of.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:33:52 UTC, Stanislav Blinov wrote: On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails... This is why the only measure is SLOC, not total lines, and one can measure SLOC easily with `dscanner --sloc` (for other languages I use sloccount). It probably counts unit tests though, which is unfortunate, but since my tests are always out-of-tree these days anyway...
Re: The #dbugfix Campaign Round 1 Report
On Tuesday, 6 November 2018 at 11:12:44 UTC, Mike Parker wrote: On Tuesday, 6 November 2018 at 08:45:13 UTC, RazvanN wrote: /the_dbugfix_campaign_round_1_report/ [...] It faded out. It went well in the first round, then I got only a handful in the second round (all from two people), then it went quiet. There were only two people actively in communication with me about volunteering, and the small pool of issues that did come in were beyond what they had the time or knowledge to fix. So without enough #bugfix posts or tweets coming in, I finally gave up. What I can do, though, is assemble a list of all of the #dbugfix tweets and forum posts that I'm aware of and send them to you. Then you can choose some to work on and we can do a blog post about it. Maybe we can get something going again from that. Sounds good. Thanks!
Re: The #dbugfix Campaign Round 1 Report
On Tuesday, 6 November 2018 at 08:45:13 UTC, RazvanN wrote: /the_dbugfix_campaign_round_1_report/ Is this still happening? If yes, I am willing to volunteer. It faded out. It went well in the first round, then I got only a handful in the second round (all from two people), then it went quiet. There were only two people actively in communication with me about volunteering, and the small pool of issues that did come in were beyond what they had the time or knowledge to fix. So without enough #bugfix posts or tweets coming in, I finally gave up. What I can do, though, is assemble a list of all of the #dbugfix tweets and forum posts that I'm aware of and send them to you. Then you can choose some to work on and we can do a blog post about it. Maybe we can get something going again from that.
Re: Wed Oct 7 - Avoiding Code Smells by Walter Bright
On Monday, 5 November 2018 at 16:50:34 UTC, Steven Schveighoffer wrote: There is a troll here posting as multiple different aliases, who has tried this before, and continually comes back to harp on the same issue. It's why I haven't participated, he doesn't need to have more encouragement. Just give it time, he will give up and go back to being a lurker. It would be good if people just stop responding here. -Steve it sounds like you're referring to me?? but which of my posts in this thread are trolling? can you show me? all most posts were resepectful, and were on the topic that I sought to discuss. false accusations are NOT appreciated! The problem is, I wanted to discuss the problems that are associated with public being the default, and private being 'kinda private'. It is the D TROLLS that ALWAYS come out to ruin that discussion by accusing me of wanting to change D. That is self-evident - just go back and read this thread - if the truth matters to you. I sought to have a decent, respectful discussion. Instead, I get D TROLLS coming out, who clearly hate OOP (and perhaps hate OO programmers), and start accusing me of wanting to turn D into an OOP language. No, I just wanted to discuss the potential benefits of increasing encapsulation within a module - that's it. Why is that so hard to do in the D forum? I don't get it. Again, get your facts straight next time. (of course, you'll likely never see this post, as there is a clear bias going on with the forum moderators too!)
Re: The #dbugfix Campaign Round 1 Report
On Monday, 14 May 2018 at 15:23:41 UTC, Mike Parker wrote: I planned an extended vacation with my wife around DConf this year and, despite my intentions before we left, fell quite far behind on my D duties. I'm in the process of getting caught up with everything, and that includes publishing the results of the first round of the #dbugfix campaign. As far as I'm concerned, it was a successful run. Now, I'm eager to improve upon it. Send some more #dbugfix nominations out into the ether and, while you're at it, volunteer to review some PRs. The issue queue isn't going to shrink all that much until the PR queue gets smaller. Thanks to everyone who nominated an issue or voiced support for a nomination in Round 1, and thanks in advance to those who will in the future! The blog: https://dlang.org/blog/2018/05/14/the-dbugfix-campaign-round-1-report/ reddit: https://www.reddit.com/r/d_language/comments/8jcz5n/the_dbugfix_campaign_round_1_report/ Is this still happening? If yes, I am willing to volunteer.
