Re: Intellij D Language plugin v1.28.0
On Monday, 6 June 2022 at 23:35:31 UTC, singingbush wrote: For anyone that likes to use Intellij, the latest release of the D Language plugin has now been published to the Jetbrains plugin repository: https://plugins.jetbrains.com/plugin/8115 I'd like to thank Etienne Brateau for contributing numerous bug fixes in this release. For a list of resolved issues see: https://github.com/intellij-dlanguage/intellij-dlanguage/milestone/32?closed=1 Thanks for finally updating the grammar! This update cleared a ton of spurious red squiggles from my code. I think the text editor is more responsive now, too.
Re: Classes in D with betterC
On Saturday, 20 November 2021 at 04:58:52 UTC, Walter Bright wrote: https://lsferreira.net/posts/zet-1-classes-betterc-d/ by Luís Ferreira Great! `__traits(initSymbol, T)` will solve some problems for my current project. Some other `class` related issues I've run into trying to get going with classes in dasBetterC: `extern(C++) class` dynamic casts are completely broken: https://issues.dlang.org/show_bug.cgi?id=21690 The GC never calls `extern(C++) class` instance destructors: https://issues.dlang.org/show_bug.cgi?id=21693 Non-mutable `extern(D) class` `scope` instances cannot be created: https://issues.dlang.org/show_bug.cgi?id=21692 Template breaks return annotation for `class` reference returned by struct method: https://issues.dlang.org/show_bug.cgi?id=22528
Re: Release Candidate [was: Re: Beta 2.095.0]
On Wednesday, 30 December 2020 at 10:51:38 UTC, Martin Nowak wrote: The release candidate for 2.095.0 is live now. It might be a good idea for someone to at least do triage on this regression I found before release: https://issues.dlang.org/show_bug.cgi?id=21513 The symptoms weren't too bad in my case (an easily worked around segmentation fault), however it seems like the kind of thing that might cause silent memory corruption in another context?
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote: The subject says it all. If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best. For everyone else, carry on as before. Great. Thanks for accepting the community's feedback. On the extern(C) issue, I wasn't convinced by your concerns about programmers taking the path of least syntactical resistance, BUT if that would really have been a serious problem, I think just keeping @system as default really is the best solution: Ideally @safe would be brainlessly easy to use, however currently it can't truly do its job without some level of understanding and effort on the part of the user. So, better to just leave the whole system off by default, than try to force it on people who can't or won't make the effort to use it correctly. (I say this even though I try to use @safe as much as possible in my own code.)
checkedint DUB package updated for the new integer promotion rules
I have updated my checkedint DUB package to work with newer compilers: https://code.dlang.org/packages/checkedint There are two significant breaking changes as a part of this: * The minimum compiler frontend version is now 2.071. * If the `-preview=intpromote` compiler option is supplied, the return types of `safeOp.unary`, `safeOp.abs`, and the corresponding `SafeInt` methods change to match the new behavior of the built-in types. See the changelog for D 2.078: https://dlang.org/changelog/2.078.0.html#fix16997 I fixed all of the deprecation warnings that I could, but there are a few that can only reasonably be removed by enabling `-preview=intpromote`. These should go away naturally once `intpromote` becomes the default. If anyone is actually using this package, please let me know either here or on GitHub if there's anything else I need to fix.
Re: Battle-plan for CTFE
On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is not supposed to be called outside of ctfe"); and static assert(!__ctfe, "This function is not supposed to be called during ctfe"); similarly you can use static if (__ctfe). Is it worth trying to get it into master ? Yes, please. I've often wished I could use `__ctfe` in a `static if`.
Re: Vision document for H2 2016
On Friday, 8 July 2016 at 18:04:16 UTC, Andrei Alexandrescu wrote: "Oops, can't let checkedint happen but I can't criticize without proposing an alternative so forget RCStr and let me work on that" ... On 07/08/2016 05:17 AM, Robert burner Schadek wrote: People would have a go to place looking for pre-approved work. Leading to no more gatekeeper rejection frustration. I don't think preapproved work would lead to less rejection. Rejection is of work of insufficient quality, not of work that has not been preapproved. Conversely, preapproval does not guarantee any work will be actually approaved. My bid for inclusion of `checkedint` in Phobos fizzled because I want to solve a different (though overlapping) set of problems than you do. No matter how much I iterate and improve my work you still won't be satisfied, because our goals are incompatible and I'm not interested in discarding mine in favor of yours. This is clear from the response you gave when I explained in some detail the reasons for my design: https://forum.dlang.org/post/njss1a$2ig5$1...@digitalmars.com Even if it were the case that there's no smaller design that conforms with the requirements, that means requirements have a problem. You neither gave any *specific* suggestions as to how I could better meet my requirements, not did you state which of my numbered requirements, *specifically* was unreasonable or unnecessary. All of the major suggestions that you did give revolved around adding new requirements (like support for arbitrary bound ranges and user-defined error handling), while somehow shrinking the code base. Something had to give. Repeatedly dismissing this obvious goals mismatch as "insufficient quality" on my part is abrasive and unhelpful. Communicating clear requirements for projects ahead of time via pre-approval could help ensure that people who volunteer are actually working on something you want. Obviously I'm not the volunteer you're looking for, but maybe if we'd all known that I wouldn't have taken ownership of the project, and someone else would already have made what you want, instead.
Re: D's Auto Decoding and You
On Friday, 3 June 2016 at 06:37:59 UTC, Rory McGuire wrote: This dpaste shows a couple of issues with combining chars in D. https://dpaste.dzfl.pl/4b006959c5c0 The compiler actually can't handle a combining character literal either. see line 10. Your paste behaves as expected: the "character" types in D are defined as single Unicode code units. By definition, the NFD form of "é" is not a single code unit. You would need to use a Grapheme or [w|d]string for that. (Of course, one might reasonably question how useful our built-in character types actually are compared to ubyte/ushort/uint.)
Re: D's Auto Decoding and You
On Friday, 3 June 2016 at 03:16:33 UTC, jmh530 wrote: I'm just looking over std.uni's section on normalization and realizing that I had basically no idea what it is or what's going on. The wikipedia page on unicode equivalence is a bit clearer. This might help a bit, as well: https://dpaste.dzfl.pl/2ffb22b02842
Re: DConf 2016 announces programme, general registration opened thrugh April 22
On Monday, 28 March 2016 at 22:30:33 UTC, Luís Marques wrote: On Monday, 28 March 2016 at 20:33:37 UTC, tsbockman wrote: The "What Parnas72 Means for D" talk sounds interesting, but I think it needs an abstract for the abstract, or a TL;DR. That was the "Extended Description" that I had submitted. The original "Abstract" section read: I have submitted a DConf.org pull request: https://github.com/D-Programming-Language/dconf.org/pull/107
Re: DConf 2016 announces programme, general registration opened thrugh April 22
On Monday, 28 March 2016 at 22:30:33 UTC, Luís Marques wrote: On Monday, 28 March 2016 at 20:33:37 UTC, tsbockman wrote: The "What Parnas72 Means for D" talk sounds interesting, but I think it needs an abstract for the abstract, or a TL;DR. That was the "Extended Description" that I had submitted. The original "Abstract" section read: David Parnas' 1972 seminal paper, "On the criteria to be used in decomposing systems into modules", set a milestone in our collective understanding of how complex programs should be divided into more manageable parts. Over forty years later, I have reimplemented in D the example programs presented in the paper and came away with insights that are not obvious from a more casual reading of that text. In this talk I will 1) present the original insight of the paper, using more modern language; 2) relate it to current design best practices and 3) argue, with the help of my implementation, that D best fulfilled the paper's original vision, even surpassing it. Yes, that looks good. That's what should be on the DConf website.
Re: DConf 2016 announces programme, general registration opened thrugh April 22
On Monday, 28 March 2016 at 16:34:55 UTC, Andrei Alexandrescu wrote: DConf 2016 Looks like a great lineup of talks this year! I intend to watch almost all of them. The "What Parnas72 Means for D" talk sounds interesting, but I think it needs an abstract for the abstract, or a TL;DR.
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 12:46:23 UTC, Ola Fosheim Grøstad wrote: On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote: Ouch yes, seen that before. I just would prefer the base library to be exactly that a base. I agree. Imagine if all the effort put into Phobos' extras was put into the compiler and tooling... It's not like you could just reallocate all the effort that goes into Phobos towards the compiler and stuff. Especially with the compiler itself, most people are unqualified or uninterested in working on it. If it were suddenly announced that Phobos was "finished", I guarantee a lot of volunteers would just walk away (likely including myself).
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 21:47:41 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote: Also, you skipped past the "uninterested" part - this is a volunteer project, remember? I didn't think it was a relevant argument as you can still write libraries for distribution. Keep in mind that the standard library has to be maintained and API's cannot easily be redesigned because of backwards compatibility. Even if C/C++ have small standard libraries they provide a depressing amount of low quality functionality that one should avoid. But it is kept in for backwards compatibility and sometimes even updated and extended... That not a good thing. There are certainly disadvantages to the standard library model of distribution and maintenance. On the other hand: 1) The prospect of getting something into the standard library is a huge motivator for (at least some) potential contributors. Why? Because building a library that no one knows about/trusts is wasted effort. Getting something into `std` is among the most effective forms of marketing available, and requires little non-programming-related skill or effort on the part of the contributor. 2) Standard libraries don't enforce backwards compatibility (and high code quality in general) just for the sake of bureaucracy - they do so because these are highly desirable characteristics for basic infrastructure. People shouldn't have to rewrite their entire stack every 6 months just because someone thought of a better API for some low-level component. Making it through D's formal review process typically raises code quality quite a lot, and the knowledge that backwards compatibility is a high priority makes outsiders much more likely to invest in actually using a library module. In short, while you make some valid points, your analysis seems very lopsided; it completely glosses over all of the positives associated with the status quo.
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote: characteristics for basic infrastructure. People shouldn't have to rewrite their entire stack every 6 months just because someone thought of a better API for some low-level component. Then don't use libraries from unreliable teams. Just using the standard library whenever possible is a simple and efficient way of accomplishing this - if the standard library actually has anything in it... Making it through D's formal review process typically raises code quality quite a lot, and the knowledge that backwards compatibility is a high priority makes outsiders much more likely to invest in actually using a library module. Code quality is one thing, but if it has not been used in many applications, how can you then know if the abstraction is particularly useful? This is why requiring modules to spend some time on DUB and/or in `std.experimental` before freezing the API is important. In general the standard library should just be the most basic things, even file system support is tricky for a system level programming language. For instance, on some cloud platforms you don't get to read/write parts of a file. You do it as one big atomic write/read. Targeting 100% generality with APIs is pretty much always a bad idea. Standard libary modules should endeavor to meet the needs of at least, say, 80% of potential users; they're not supposed to completely eliminate the need for specialized third-party libraries entirely. This is OK, because if you don't use a module, the compiler won't include it in the final executable.
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote: Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei Something went wrong here: We fell short of our 2000 pull requests goal in H2 2015. We have had only 1 1378 pull requests. In addition to the extraneous "1", the link is bad: "No results matched your search."
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote: The strategy should be "get rid of anything in Phobos that can be put out as a separate library". This makes no sense as a standard: since neither DMD nor druntime is allowed to depend upon Phobos, everything in Phobos *could* be put into a separate library.
Re: LDC 0.17.0-beta1 has been released!
On Monday, 18 January 2016 at 15:47:07 UTC, Manu wrote: Love your work guys! Thanks for keeping at it. One question though, what's the plan for moving to DMD latest? Both LDC and GDC seem to be quite behind at the moment. My current project is depending on bug-fixes patched in by Walter in the last few days, so I'm stuck with DMD for the moment. GDC 2.067 is getting close: https://github.com/ibuclaw/GDC/commits/2.067
Re: New D tool releases
On Thursday, 14 January 2016 at 09:05:09 UTC, Brian Schott wrote: dfmt: Code formatter 0.4.2 http://code.dlang.org/packages/dfmt https://github.com/Hackerpilot/dfmt/releases/tag/v0.4.2 You forgot to bump the version number: dfmt --version 0.4.1
Re: Andrei on Optimization
On Friday, 8 January 2016 at 13:30:34 UTC, Walter Bright wrote: Part 2: https://www.youtube.com/watch?v=3_FXy3cT5C8 Inspiration for a new logo? :P http://www.youtube.com/watch?v=3_FXy3cT5C8=47m50s
Re: Beta D 2.070.0-b1
On Sunday, 3 January 2016 at 19:24:57 UTC, Martin Nowak wrote: First beta for the 2.070.0 release. Any hope for this? https://github.com/D-Programming-Language/dmd/pull/3407#issuecomment-136974686 It's been bugging a lot of people lately.
