From johan_forsberg_86 at hotmail.com Thu Oct 1 07:02:12 2020 From: johan_forsberg_86 at hotmail.com (Imperatorn) Date: Thu, 01 Oct 2020 07:02:12 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: > On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn > wrote: >> On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak >> wrote: >>> Glad to announce D 2.094.0, ? to the 49 contributors. >>> >>> This release comes with faster compiler binaries (built with >>> ldc), direct git dependencies in dub, better type checking of >>> vectors, and improved template instantiation diagnostics. >>> >>> http://dlang.org/download.html >>> http://dlang.org/changelog/2.094.0.html >>> >>> -Martin >> >> Hurrah! ?? > > Yay! "-preview=in" is beyond epic! I like epic things. What does it do? :D From user1234 at 12.de Thu Oct 1 07:29:44 2020 From: user1234 at 12.de (user1234) Date: Thu, 01 Oct 2020 07:29:44 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote: > On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: >> On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn >> wrote: >>> On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak >>> wrote: >>>> Glad to announce D 2.094.0, ? to the 49 contributors. >>>> >>>> This release comes with faster compiler binaries (built with >>>> ldc), direct git dependencies in dub, better type checking >>>> of vectors, and improved template instantiation diagnostics. >>>> >>>> http://dlang.org/download.html >>>> http://dlang.org/changelog/2.094.0.html >>>> >>>> -Martin >>> >>> Hurrah! ?? >> >> Yay! "-preview=in" is beyond epic! > > I like epic things. What does it do? :D "in" parameter storage class used to be like "const". with the preview it has its own semantics, i.e like "scope const". But it's a preview because people tend to use "in" because it was shorter than "const" so many code base are poisoned with this misuse (although in plenty of case the new semantics probably dont cause bugs...) From johan_forsberg_86 at hotmail.com Thu Oct 1 07:43:38 2020 From: johan_forsberg_86 at hotmail.com (Imperatorn) Date: Thu, 01 Oct 2020 07:43:38 +0000 Subject: Sociomantic Tsunami now under new community maintainership In-Reply-To: References: Message-ID: On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw wrote: > Hello Everybody, > > Tsunami is a set of core libraries, applications, and tools > that were used at > sociomantic labs/dunnhumby Germany, and have been available as > open-source > software since 2017 under the direction and management of > dunnhumby. > > [...] Cool. Are those projects on dub as well? From joseph.wakeling at webdrake.net Thu Oct 1 09:24:58 2020 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 01 Oct 2020 09:24:58 +0000 Subject: Sociomantic Tsunami now under new community maintainership In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 07:43:38 UTC, Imperatorn wrote: > On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw > wrote: >> Hello Everybody, >> >> Tsunami is a set of core libraries, applications, and tools >> that were used at >> sociomantic labs/dunnhumby Germany, and have been available as >> open-source >> software since 2017 under the direction and management of >> dunnhumby. >> >> [...] > > Cool. Are those projects on dub as well? Ocean is up to date and on dub: https://code.dlang.org/packages/ocean Adding dub config to the other projects is planned, and we'd welcome patches if anyone wants to speed up that process. From joseph.wakeling at webdrake.net Thu Oct 1 09:27:26 2020 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 01 Oct 2020 09:27:26 +0000 Subject: Sociomantic Tsunami now under new community maintainership In-Reply-To: References: Message-ID: On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw wrote: > I would like to thank dunnhumby for being supportive throughout > the entire process, and for handling the transition in a > gracious > fashion since operations began winding down. I would second those thanks, and would also like to offer a big hand to Iain for stewarding this whole process. From geod24 at gmail.com Thu Oct 1 09:49:36 2020 From: geod24 at gmail.com (Mathias LANG) Date: Thu, 01 Oct 2020 09:49:36 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote: > On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: >> On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn >> wrote: >>> On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak >>> wrote: >>>> Glad to announce D 2.094.0, ? to the 49 contributors. >>>> >>>> This release comes with faster compiler binaries (built with >>>> ldc), direct git dependencies in dub, better type checking >>>> of vectors, and improved template instantiation diagnostics. >>>> >>>> http://dlang.org/download.html >>>> http://dlang.org/changelog/2.094.0.html >>>> >>>> -Martin >>> >>> Hurrah! ?? >> >> Yay! "-preview=in" is beyond epic! > > I like epic things. What does it do? :D Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. From Petar Thu Oct 1 13:45:21 2020 From: Petar (Petar) Date: Thu, 01 Oct 2020 13:45:21 +0000 Subject: Sociomantic Tsunami now under new community maintainership In-Reply-To: References: Message-ID: On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw wrote: > [..] Great news, thank you Iain and everyone else who was responsible! I think an overview of those D projects would make for a great DConf talk! From jared771 at gmail.com Thu Oct 1 14:36:18 2020 From: jared771 at gmail.com (Meta) Date: Thu, 01 Oct 2020 14:36:18 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: > Author here. The most complete way to know would be to read the > changelog: https://dlang.org/changelog/2.094.0.html#preview-in > The TL;DR is that, in addition to `const scope`, `in` now > automatically behaves as `ref` when "it makes sense" such as > large value types or presence of destructors / postblit (more > details in the changelog!) and will accept rvalues, unlike > other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same. From schveiguy at gmail.com Thu Oct 1 16:19:48 2020 From: schveiguy at gmail.com (Steven Schveighoffer) Date: Thu, 1 Oct 2020 12:19:48 -0400 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On 10/1/20 10:36 AM, Meta wrote: > On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: >> Author here. The most complete way to know would be to read the >> changelog: https://dlang.org/changelog/2.094.0.html#preview-in >> The TL;DR is that, in addition to `const scope`, `in` now >> automatically behaves as `ref` when "it makes sense" such as large >> value types or presence of destructors / postblit (more details in the >> changelog!) and will accept rvalues, unlike other ref parameters. > > Why was this added when we already have `auto ref`? Yes, it makes the > function a template, but if `in` can automatically choose whether the > variable is ref or not, then auto ref could easily do the same. There is a difference. `in` is choosing it based on the type, not whether it's an rvalue or lvalue. auto ref doesn't care whether it's an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's an rvalue, it's non-ref. Not only that, but every auto-ref parameter is another template parameter varying on the usage. So calling on an lvalue and rvalue will generate 2 separate mostly-identical functions. With -preview=in, only one function is generated per type. -Steve From john.michael.hall at gmail.com Thu Oct 1 16:44:09 2020 From: john.michael.hall at gmail.com (jmh530) Date: Thu, 01 Oct 2020 16:44:09 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: > [snip] > > Author here. The most complete way to know would be to read the > changelog: https://dlang.org/changelog/2.094.0.html#preview-in > The TL;DR is that, in addition to `const scope`, `in` now > automatically behaves as `ref` when "it makes sense" such as > large value types or presence of destructors / postblit (more > details in the changelog!) and will accept rvalues, unlike > other ref parameters. Typo from the link "However, this didn't really capture the intended meaning of in: the be applied on input parameters. " From john.michael.hall at gmail.com Thu Oct 1 16:44:59 2020 From: john.michael.hall at gmail.com (jmh530) Date: Thu, 01 Oct 2020 16:44:59 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 16:44:09 UTC, jmh530 wrote: >[snip] > > Typo from the link > > "However, this didn't really capture the intended meaning of > in: the be applied on input parameters. " It looks like that whole paragraph has a bunch of typos... From jared771 at gmail.com Thu Oct 1 16:47:37 2020 From: jared771 at gmail.com (Meta) Date: Thu, 01 Oct 2020 16:47:37 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 16:19:48 UTC, Steven Schveighoffer wrote: > On 10/1/20 10:36 AM, Meta wrote: >> On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG >> wrote: >>> Author here. The most complete way to know would be to read >>> the changelog: >>> https://dlang.org/changelog/2.094.0.html#preview-in >>> The TL;DR is that, in addition to `const scope`, `in` now >>> automatically behaves as `ref` when "it makes sense" such as >>> large value types or presence of destructors / postblit (more >>> details in the changelog!) and will accept rvalues, unlike >>> other ref parameters. >> >> Why was this added when we already have `auto ref`? Yes, it >> makes the function a template, but if `in` can automatically >> choose whether the variable is ref or not, then auto ref could >> easily do the same. > > There is a difference. `in` is choosing it based on the type, > not whether it's an rvalue or lvalue. auto ref doesn't care > whether it's an int or a 1k-sized struct, if it's an lvalue, > it's ref, and if it's an rvalue, it's non-ref. This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? > Not only that, but every auto-ref parameter is another template > parameter varying on the usage. So calling on an lvalue and > rvalue will generate 2 separate mostly-identical functions. > > With -preview=in, only one function is generated per type. That's a QOI problem IMO. > -Steve From schveiguy at gmail.com Thu Oct 1 17:03:10 2020 From: schveiguy at gmail.com (Steven Schveighoffer) Date: Thu, 1 Oct 2020 13:03:10 -0400 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On 10/1/20 12:47 PM, Meta wrote: > On Thursday, 1 October 2020 at 16:19:48 UTC, Steven Schveighoffer wrote: >> >> There is a difference. `in` is choosing it based on the type, not >> whether it's an rvalue or lvalue. auto ref doesn't care whether it's >> an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's >> an rvalue, it's non-ref. > > This seems ridiculous to me. We now have ANOTHER way of asking the > compiler to choose for us whether to pass by ref or by value, completely > mutually exclusive of auto ref. Where was the DIP (apologies if I just > didn't see it)? Did Walter approve this? How do we explain the > difference between in and auto ref with (as Andrei would say) a straight > face? Whether a *const* piece of data is passed by reference or value is an implementation detail -- you can't change it anyway. I don't want the compiler to pass const integers by reference -- that's wasteful. auto ref is a different problem -- the data might be mutable, which makes an actual difference in semantics. But this brings up a problem which I don't know if it was discussed -- aliasing. What if you pass in the same value in 2 parameters, one ref and one in. And you change the value via the ref. What happens to the in parameter? -Steve From Petar Thu Oct 1 17:24:17 2020 From: Petar (Petar) Date: Thu, 01 Oct 2020 17:24:17 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: > On Thursday, 1 October 2020 at 16:19:48 UTC, Steven > Schveighoffer wrote: >> On 10/1/20 10:36 AM, Meta wrote: >>> On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG >>> wrote: >>>> Author here. The most complete way to know would be to read >>>> the changelog: >>>> https://dlang.org/changelog/2.094.0.html#preview-in >>>> The TL;DR is that, in addition to `const scope`, `in` now >>>> automatically behaves as `ref` when "it makes sense" such as >>>> large value types or presence of destructors / postblit >>>> (more details in the changelog!) and will accept rvalues, >>>> unlike other ref parameters. >>> >>> Why was this added when we already have `auto ref`? Yes, it >>> makes the function a template, but if `in` can automatically >>> choose whether the variable is ref or not, then auto ref >>> could easily do the same. >> >> There is a difference. `in` is choosing it based on the type, >> not whether it's an rvalue or lvalue. auto ref doesn't care >> whether it's an int or a 1k-sized struct, if it's an lvalue, >> it's ref, and if it's an rvalue, it's non-ref. > > This seems ridiculous to me. We now have ANOTHER way of asking > the compiler to choose for us whether to pass by ref or by > value, completely mutually exclusive of auto ref. Where was the > DIP (apologies if I just didn't see it)? Did Walter approve > this? How do we explain the difference between in and auto ref > with (as Andrei would say) a straight face? `auto ref` is a mistake and shouldn't have existed. Thanks to Mathias, `in` parameters are finally working the way most sane people expect them to work. I can't quite explain `auto ref` with straight face, while to explain `in` I just need to say "unless you're mutating or aliasing the parameter always mark it as `in`". >> Not only that, but every auto-ref parameter is another >> template parameter varying on the usage. So calling on an >> lvalue and rvalue will generate 2 separate mostly-identical >> functions. >> >> With -preview=in, only one function is generated per type. > > That's a QOI problem IMO. > No, it's not. According the spec, `auto ref` parameters can only be used for templates (making them useless for virtual functions and delegates) and the compiler is required to generate a different functions depending on whether the parameter is an lvalue or an rvalue, which completely misses the point. There's code out there that expect two instances to be generated and distinguishes which one it's in using `static if (__traits(isRef, param))`. You can't change this behavior without breaking code, so it's not a QoI problem. On the other hand, now the `in` parameter storage class finally has the opposite meaning of `out`. Makes code more elegant to write, easier to explain and teach. From geod24 at gmail.com Thu Oct 1 17:29:56 2020 From: geod24 at gmail.com (Mathias LANG) Date: Thu, 01 Oct 2020 17:29:56 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: > > This seems ridiculous to me. We now have ANOTHER way of asking > the compiler to choose for us whether to pass by ref or by > value, completely mutually exclusive of auto ref. Where was the > DIP (apologies if I just didn't see it)? Did Walter approve > this? How do we explain the difference between in and auto ref > with (as Andrei would say) a straight face? Yes we have a 3rd way. Because `auto ref` just doesn't cut it for most usages, and `-preview=rvaluerefparam` never worked. You can have a look at the full discussion in the PR that introduced it (dmd#11000). I try to summarize a few arguments in favor of it here: https://github.com/dlang/dmd/pull/11000#issuecomment-674498704 As you can see from the discussion, it's not really something that was quickly merged, but the results of months of work. So while it might seems "ridiculous" to you, I'd appreciate if you could take the time to read through the discussion, as well as taking a look at Herb Sutter's presentation which was linked. The key takeaway from that presentation is that instead of having the users specify *how* to pass the parameter, they should specify what is the parameter's semantic. In our case, input (in), output (out), or input/output (ref). I'm not aware of a situation where you want to use `auto ref` on a parameter without `const` (or `const` semantic), because if you intend to modify the parameter, you need to be sure whether it's `ref` or not. I'm aware some people use it for forwarding but this has its own set of problem. From noone at nowhere.com Thu Oct 1 18:04:35 2020 From: noone at nowhere.com (kinke) Date: Thu, 01 Oct 2020 18:04:35 +0000 Subject: LDC 1.24.0-beta1 Message-ID: Glad to announce the first beta for LDC 1.24: - Based on D 2.094.0+. - Support for LLVM 11. The prebuilt packages use v11.0.0-rc4+, and the x86 packages newly include the LLVM backend for AMD GPUs. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.24.0-beta1 Please help test, and thanks to all contributors & sponsors! From jared771 at gmail.com Thu Oct 1 18:29:14 2020 From: jared771 at gmail.com (Meta) Date: Thu, 01 Oct 2020 18:29:14 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 17:29:56 UTC, Mathias LANG wrote: > On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: >> >> This seems ridiculous to me. We now have ANOTHER way of asking >> the compiler to choose for us whether to pass by ref or by >> value, completely mutually exclusive of auto ref. Where was >> the DIP (apologies if I just didn't see it)? Did Walter >> approve this? How do we explain the difference between in and >> auto ref with (as Andrei would say) a straight face? > > Yes we have a 3rd way. Because `auto ref` just doesn't cut it > for most usages, and `-preview=rvaluerefparam` never worked. > > You can have a look at the full discussion in the PR that > introduced it (dmd#11000). > I try to summarize a few arguments in favor of it here: > https://github.com/dlang/dmd/pull/11000#issuecomment-674498704 > > As you can see from the discussion, it's not really something > that was quickly merged, but the results of months of work. So > while it might seems "ridiculous" to you, I'd appreciate if you > could take the time to read through the discussion, as well as > taking a look at Herb Sutter's presentation which was linked. > > The key takeaway from that presentation is that instead of > having the users specify *how* to pass the parameter, they > should specify what is the parameter's semantic. In our case, > input (in), output (out), or input/output (ref). > > I'm not aware of a situation where you want to use `auto ref` > on a parameter without `const` (or `const` semantic), because > if you intend to modify the parameter, you need to be sure > whether it's `ref` or not. I'm aware some people use it for > forwarding but this has its own set of problem. I've read the discussion but skipped the presentation. All I see is Atila expressing distaste for the compiler choosing how to pass values, and no explicit sign-off from either Walter or Atila before it was merged. My objection is not to `in`'s new behaviour (although having something that functions similarly to auto ref but in subtly different ways is not good language design, IMO). My objection is that we have a major change to a language feature, that was merged without the apparent blessing of either of the two people who are supposed to be the gatekeepers for these decisions, and without a DIP (yes, it is behind -preview, but that implies that this will eventually make it into the language proper). That is what I am calling "ridiculous". If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. From noone at nowhere.com Thu Oct 1 20:37:04 2020 From: noone at nowhere.com (kinke) Date: Thu, 01 Oct 2020 20:37:04 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: > If W or A did approve it and I just wasn't aware, then I > apologize and retract my objection. https://github.com/dlang/dmd/pull/11000#issuecomment-675605193 From seb at wilzba.ch Thu Oct 1 20:40:39 2020 From: seb at wilzba.ch (Seb) Date: Thu, 01 Oct 2020 20:40:39 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: > On Thursday, 1 October 2020 at 17:29:56 UTC, Mathias LANG wrote: >> On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: >>> [...] >> >> Yes we have a 3rd way. Because `auto ref` just doesn't cut it >> for most usages, and `-preview=rvaluerefparam` never worked. >> >> You can have a look at the full discussion in the PR that >> introduced it (dmd#11000). >> I try to summarize a few arguments in favor of it here: >> https://github.com/dlang/dmd/pull/11000#issuecomment-674498704 >> >> As you can see from the discussion, it's not really something >> that was quickly merged, but the results of months of work. So >> while it might seems "ridiculous" to you, I'd appreciate if >> you could take the time to read through the discussion, as >> well as taking a look at Herb Sutter's presentation which was >> linked. >> >> The key takeaway from that presentation is that instead of >> having the users specify *how* to pass the parameter, they >> should specify what is the parameter's semantic. In our case, >> input (in), output (out), or input/output (ref). >> >> I'm not aware of a situation where you want to use `auto ref` >> on a parameter without `const` (or `const` semantic), because >> if you intend to modify the parameter, you need to be sure >> whether it's `ref` or not. I'm aware some people use it for >> forwarding but this has its own set of problem. > > I've read the discussion but skipped the presentation. All I > see is Atila expressing distaste for the compiler choosing how > to pass values, and no explicit sign-off from either Walter or > Atila before it was merged. > > My objection is not to `in`'s new behaviour (although having > something that functions similarly to auto ref but in subtly > different ways is not good language design, IMO). My objection > is that we have a major change to a language feature, that was > merged without the apparent blessing of either of the two > people who are supposed to be the gatekeepers for these > decisions, and without a DIP (yes, it is behind -preview, but > that implies that this will eventually make it into the > language proper). That is what I am calling "ridiculous". If W > or A did approve it and I just wasn't aware, then I apologize > and retract my objection. You seem to have a wrong understanding of -preview. It doesn't even pretend to be an officially approved feature. I think this is what's been causing the confusion. Preview flags are what other compilers call "experimental". In fact, -preview is intended to predate a DIP or formal approval in other ways, because if you don't know the impact of a feature or usefulness, it's very hard to make an informed decision. This has the nice side effect that sometimes it becomes clear during an implementation that the idea as is unfeasible. > implies that this will eventually make it into the language > proper No, it doesn't. From jared771 at gmail.com Thu Oct 1 21:08:47 2020 From: jared771 at gmail.com (Meta) Date: Thu, 01 Oct 2020 21:08:47 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote: > On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: >> If W or A did approve it and I just wasn't aware, then I >> apologize and retract my objection. > > https://github.com/dlang/dmd/pull/11000#issuecomment-675605193 As far as I understand it, Andrei does not have any say over the direction of the language anymore since he stepped down. By "W or A" I meant "Walter or Atila". From jared771 at gmail.com Thu Oct 1 21:09:55 2020 From: jared771 at gmail.com (Meta) Date: Thu, 01 Oct 2020 21:09:55 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: > On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: >> I've read the discussion but skipped the presentation. All I >> see is Atila expressing distaste for the compiler choosing how >> to pass values, and no explicit sign-off from either Walter or >> Atila before it was merged. >> >> My objection is not to `in`'s new behaviour (although having >> something that functions similarly to auto ref but in subtly >> different ways is not good language design, IMO). My objection >> is that we have a major change to a language feature, that was >> merged without the apparent blessing of either of the two >> people who are supposed to be the gatekeepers for these >> decisions, and without a DIP (yes, it is behind -preview, but >> that implies that this will eventually make it into the >> language proper). That is what I am calling "ridiculous". If W >> or A did approve it and I just wasn't aware, then I apologize >> and retract my objection. > > You seem to have a wrong understanding of -preview. It doesn't > even pretend to be an officially approved feature. I think this > is what's been causing the confusion. > > Preview flags are what other compilers call "experimental". In > fact, -preview is intended to predate a DIP or formal approval > in other ways, because if you don't know the impact of a > feature or usefulness, it's very hard to make an informed > decision. > > This has the nice side effect that sometimes it becomes clear > during an implementation that the idea as is unfeasible. > >> implies that this will eventually make it into the language >> proper > > No, it doesn't. Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview? From seb at wilzba.ch Thu Oct 1 21:19:02 2020 From: seb at wilzba.ch (Seb) Date: Thu, 01 Oct 2020 21:19:02 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote: > On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: >> [...] > > Okay, fair enough. Should this still not have had approval from > either Walter or Atila before being merged in? Or is that not > the case for changes behind -preview? Approval is not required for -preview. It's the testing phase of a new feature or change. As I tried to mention earlier real data and experimentation is super helpful for a DIP / formal approval (in this case one important question answered was how much code in the D ecosystem would need to be changed). There's a bit of implicit approval by no objection as something that's worthwhile to be explored/tested, but it's only a good chance that it will be activated by default, not a guarantee. From jared771 at gmail.com Thu Oct 1 21:27:19 2020 From: jared771 at gmail.com (Meta) Date: Thu, 01 Oct 2020 21:27:19 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 21:19:02 UTC, Seb wrote: > On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote: >> On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: >>> [...] >> >> Okay, fair enough. Should this still not have had approval >> from either Walter or Atila before being merged in? Or is that >> not the case for changes behind -preview? > > Approval is not required for -preview. It's the testing phase > of a new feature or change. As I tried to mention earlier real > data and experimentation is super helpful for a DIP / formal > approval (in this case one important question answered was how > much code in the D ecosystem would need to be changed). > > There's a bit of implicit approval by no objection as something > that's worthwhile to be explored/tested, but it's only a good > chance that it will be activated by default, not a guarantee. Okay, fair enough. Looks like I was mistaken and thought -preview implied that the feature will be moved out from under the switch after a certain number of releases (as the word "preview" means an early look at something that will be released in the future). From johan_forsberg_86 at hotmail.com Fri Oct 2 13:55:00 2020 From: johan_forsberg_86 at hotmail.com (Imperatorn) Date: Fri, 02 Oct 2020 13:55:00 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: > On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote: >> On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: >>> On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn >>> wrote: >>>> [...] >>> >>> Yay! "-preview=in" is beyond epic! >> >> I like epic things. What does it do? :D > > Author here. The most complete way to know would be to read the > changelog: https://dlang.org/changelog/2.094.0.html#preview-in > The TL;DR is that, in addition to `const scope`, `in` now > automatically behaves as `ref` when "it makes sense" such as > large value types or presence of destructors / postblit (more > details in the changelog!) and will accept rvalues, unlike > other ref parameters. Thanks for the clarification From SeeWebsiteForEmail at erdani.com Fri Oct 2 14:08:06 2020 From: SeeWebsiteForEmail at erdani.com (Andrei Alexandrescu) Date: Fri, 2 Oct 2020 10:08:06 -0400 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On 10/1/20 5:08 PM, Meta wrote: > On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote: >> On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: >>> If W or A did approve it and I just wasn't aware, then I apologize >>> and retract my objection. >> >> https://github.com/dlang/dmd/pull/11000#issuecomment-675605193 > > As far as I understand it, Andrei does not have any say over the > direction of the language anymore since he stepped down. By "W or A" I > meant "Walter or Atila". That is correct, thanks for clarifying. Related: thanks Mathias for working on improving the status quo in function parameter modifiers. Any shake of that rusty nail is likely to improve matters. From ajieskola at gmail.com Sat Oct 3 04:31:35 2020 From: ajieskola at gmail.com (Dukc) Date: Sat, 03 Oct 2020 04:31:35 +0000 Subject: DConf Online 2020... In-Reply-To: References: Message-ID: Did you remember the schelude publication? It was supposed to happen yesterday. From aldacron at gmail.com Sat Oct 3 04:33:51 2020 From: aldacron at gmail.com (Mike Parker) Date: Sat, 03 Oct 2020 04:33:51 +0000 Subject: DConf Online 2020... In-Reply-To: References: Message-ID: On Saturday, 3 October 2020 at 04:31:35 UTC, Dukc wrote: > Did you remember the schelude publication? It was supposed to > happen yesterday. Yes. I'm behind schedule, but it's coming soon. From newshound2 at digitalmars.com Sat Oct 3 23:12:33 2020 From: newshound2 at digitalmars.com (Walter Bright) Date: Sat, 3 Oct 2020 16:12:33 -0700 Subject: DConf Online 2020... In-Reply-To: References: Message-ID: What's the hashtag? #dconf2020 ? From acehreli at yahoo.com Sat Oct 3 23:15:41 2020 From: acehreli at yahoo.com (=?UTF-8?Q?Ali_=c3=87ehreli?=) Date: Sat, 3 Oct 2020 16:15:41 -0700 Subject: DConf Online 2020... In-Reply-To: References: Message-ID: On 10/3/20 4:12 PM, Walter Bright wrote: > What's the hashtag? #dconf2020 ? Me not know hashtag but Mike has been saying that this is not a DConf but a "DConf Online". Two different yearly events... :) Ali From aldacron at gmail.com Sat Oct 3 23:37:37 2020 From: aldacron at gmail.com (Mike Parker) Date: Sat, 03 Oct 2020 23:37:37 +0000 Subject: DConf Online 2020... In-Reply-To: References: Message-ID: On Saturday, 3 October 2020 at 23:15:41 UTC, Ali ?ehreli wrote: > On 10/3/20 4:12 PM, Walter Bright wrote: >> What's the hashtag? #dconf2020 ? > > Me not know hashtag but Mike has been saying that this is not a > DConf but a "DConf Online". Two different yearly events... :) > > Ali #dconf2020 works. From aldacron at gmail.com Sun Oct 4 03:33:54 2020 From: aldacron at gmail.com (Mike Parker) Date: Sun, 04 Oct 2020 03:33:54 +0000 Subject: DConf Online 2020... In-Reply-To: References: Message-ID: On Saturday, 3 October 2020 at 23:37:37 UTC, Mike Parker wrote: > On Saturday, 3 October 2020 at 23:15:41 UTC, Ali ?ehreli wrote: >> On 10/3/20 4:12 PM, Walter Bright wrote: >>> What's the hashtag? #dconf2020 ? >> >> Me not know hashtag but Mike has been saying that this is not >> a DConf but a "DConf Online". Two different yearly events... :) >> >> Ali > > #dconf2020 works. I thought the question was regarding the forums. For twitter, I've always just used #dconf. From feepingcreature at gmail.com Sun Oct 4 17:05:17 2020 From: feepingcreature at gmail.com (FeepingCreature) Date: Sun, 04 Oct 2020 17:05:17 +0000 Subject: DConf Online 2020... In-Reply-To: References: Message-ID: On Tuesday, 8 September 2020 at 09:17:10 UTC, Mike Parker wrote: > I was on the verge to cutting the schedule down to one day, but > thanks to some last-minute submissions, looks like we'll have > enough content now to stretch across two days! > > Thanks to everyone who submitted a proposal. I'll be in touch > with each of you soon to discuss how to proceed. For everyone > else, keep an eye on the DConf Online 2020 homepage for the > schedule and other announcements. We're supposed to submit a five-minute sample no later than the 4th of October. And I just realized that technically, given the West Coast timezone is nine hours behind Germany, I can actually record mine at 6am at work tomorrow and still be comfortably on time. Which means I don't need to do it on a Sunday!~ Should I stop routinely pushing things out until the very last conceivable moment? *Maybe...* But clearly not today. :) From alireza6677 at gmail.com Sun Oct 4 19:07:35 2020 From: alireza6677 at gmail.com (Alireza SN) Date: Sun, 04 Oct 2020 19:07:35 +0000 Subject: [Release] Authomata: a two-factor authentication gui app for Gnu/Linux Message-ID: This weekend i had some free time and wrote this GtkD app for two-factor authentication (yes i know there are alternatives but it's a cool little project). It still lacks a lot of functionality like edit/delete/import/export but the config file (~/.config/Authomata/config.json) is a json array so it's pretty easy make a backup or edit manually. Give it a try: https://github.com/TheWeirdDev/Authomata I will add more features in the upcoming weekends :) From jond at noreply.com Sun Oct 4 19:54:34 2020 From: jond at noreply.com (Jon Degenhardt) Date: Sun, 04 Oct 2020 19:54:34 +0000 Subject: Github Actions now support D out of the box! In-Reply-To: References: Message-ID: On Friday, 21 August 2020 at 02:03:40 UTC, Mathias LANG wrote: > Hi everyone, > Almost a year ago, Ernesto Castelloti (@ErnyTech) submitted a > PR for Github's "starter-workflow" to add support for D out of > the box (https://github.com/actions/starter-workflows/pull/74). > It was in a grey area for a while, as Github was trying to come > up with a policy for external actions. I ended up picking up > the project, after working with actions extensively for my own > projects and the dlang org, and my PR was finally merged > yesterday > (https://github.com/actions/starter-workflows/pull/546). A thank you to everyone who helped put this together. I just started using it, and it works quite well. It's a very valuable tool to have! --Jon From andrej.mitrovich at gmail.com Mon Oct 5 03:27:22 2020 From: andrej.mitrovich at gmail.com (Andrej Mitrovic) Date: Mon, 05 Oct 2020 03:27:22 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: > Glad to announce D 2.094.0, ? to the 49 contributors. > > This release comes with faster compiler binaries (built with > ldc), direct git dependencies in dub, better type checking of > vectors, and improved template instantiation diagnostics. > > http://dlang.org/download.html > http://dlang.org/changelog/2.094.0.html > > -Martin ``` $ curl -fsS https://dlang.org/install.sh | bash -s dmd Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.094.0/dmd.2.094.0.osx.tar.xz ######################################################################## 100.0% gpg: Signature made Tue Sep 22 18:58:37 2020 KST gpg: using RSA key 3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8 gpg: Can't check signature: No public key Invalid signature http://downloads.dlang.org/releases/2.x/2.094.0/dmd.2.094.0.osx.tar.xz.sig ``` I'm not sure if it's related to https://issues.dlang.org/show_bug.cgi?id=21226. But how many people will be turned away not being able to install the compiler? From andrej.mitrovich at gmail.com Mon Oct 5 09:17:13 2020 From: andrej.mitrovich at gmail.com (Andrej Mitrovic) Date: Mon, 05 Oct 2020 09:17:13 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Monday, 5 October 2020 at 03:27:22 UTC, Andrej Mitrovic wrote: > I'm not sure if it's related to > https://issues.dlang.org/show_bug.cgi?id=21226. But how many > people will be turned away not being able to install the > compiler? This might have come off a bit rude, apologies for that. That being said, the solution seemed to be to run the `update` command on the script. It wasn't really obvious though. From first.name at gmail.com Mon Oct 5 11:59:46 2020 From: first.name at gmail.com (Guillaume Piolat) Date: Mon, 05 Oct 2020 11:59:46 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 18:04:35 UTC, kinke wrote: > Glad to announce the first beta for LDC 1.24: > > - Based on D 2.094.0+. > - Support for LLVM 11. > The prebuilt packages use v11.0.0-rc4+, and the x86 packages > newly include the LLVM backend for AMD GPUs. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.24.0-beta1 > > Please help test, and thanks to all contributors & sponsors! Thanks! Now supported by https://github.com/AuburnSounds/intel-intrinsics and tests pass. The new __vector conversion rules are cool and would hopefully avoid bugs. Not too sure about int being implicitly convertible to __vector(int[N]) but we also have that for static arrays it seems. From notna.remove.this at ist-einmalig.de Mon Oct 5 13:56:51 2020 From: notna.remove.this at ist-einmalig.de (notna) Date: Mon, 05 Oct 2020 13:56:51 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Monday, 5 October 2020 at 09:17:13 UTC, Andrej Mitrovic wrote: > On Monday, 5 October 2020 at 03:27:22 UTC, Andrej Mitrovic > wrote: >> I'm not sure if it's related to >> https://issues.dlang.org/show_bug.cgi?id=21226. But how many >> people will be turned away not being able to install the >> compiler? > > This might have come off a bit rude, apologies for that. > > That being said, the solution seemed to be to run the `update` > command on the script. It wasn't really obvious though. Well, the "signature" topic is a constantly reoccurring issue and you can find plenty complains in the news group / forum... some examples: - https://forum.dlang.org/post/mailman.3930.1592291554.31109.digitalmars-d-bugs at puremagic.com - https://forum.dlang.org/post/mailman.2853.1587904820.31109.digitalmars-d-bugs at puremagic.com - https://forum.dlang.org/post/fnaizrmuezxobtxlauci at forum.dlang.org - https://forum.dlang.org/post/lwsekmmdlmfkhkahmucu at forum.dlang.org - https://forum.dlang.org/post/szvratfzlyfbjeumabiy at forum.dlang.org - https://forum.dlang.org/post/hpdxzlxwofpktlaaokuz at forum.dlang.org I made a quick enhancement proposal as suggested by Seb before / here - https://github.com/dlang/dlang.org/pull/2817#pullrequestreview-425842582 ... my pull request was merged but later reverted again: - https://github.com/dlang/installer/pull/457 - https://github.com/dlang/installer/pull/302 Seb promised to work on it... whenever he finds the need and time for it. Mybe someone else can continue / implement / drive this "auto update" topic... regards From andre at s-e-a-p.de Mon Oct 5 14:51:41 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Mon, 05 Oct 2020 14:51:41 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Monday, 5 October 2020 at 13:56:51 UTC, notna wrote: > On Monday, 5 October 2020 at 09:17:13 UTC, Andrej Mitrovic > wrote: >> [...] > > Well, the "signature" topic is a constantly reoccurring issue > and you can find plenty complains in the news group / forum... > some examples: > - > https://forum.dlang.org/post/mailman.3930.1592291554.31109.digitalmars-d-bugs at puremagic.com > - > https://forum.dlang.org/post/mailman.2853.1587904820.31109.digitalmars-d-bugs at puremagic.com > > [...] I thought someone proposed to enhance the error message with the info about the update command. This would be a starting point and easy to implement. Kind regards Andre From karabutaworld at gmail.com Mon Oct 5 17:25:04 2020 From: karabutaworld at gmail.com (aberba) Date: Mon, 05 Oct 2020 17:25:04 +0000 Subject: [Release] Authomata: a two-factor authentication gui app for Gnu/Linux In-Reply-To: References: Message-ID: On Sunday, 4 October 2020 at 19:07:35 UTC, Alireza SN wrote: > This weekend i had some free time and wrote this GtkD app for > two-factor authentication (yes i know there are alternatives > but it's a cool little project). > > It still lacks a lot of functionality like > edit/delete/import/export but the config file > (~/.config/Authomata/config.json) is a json array so it's > pretty easy make a backup or edit manually. > > Give it a try: > https://github.com/TheWeirdDev/Authomata > > I will add more features in the upcoming weekends :) Nice. Will you publish it on flathub or snap store eventually? From alireza6677 at gmail.com Mon Oct 5 17:56:09 2020 From: alireza6677 at gmail.com (Alireza SN) Date: Mon, 05 Oct 2020 17:56:09 +0000 Subject: [Release] Authomata: a two-factor authentication gui app for Gnu/Linux In-Reply-To: References: Message-ID: On Monday, 5 October 2020 at 17:25:04 UTC, aberba wrote: > Nice. Will you publish it on flathub or snap store eventually? Thanks. I will build packages for Arch Linux and Ubuntu (Maybe AppImage too) but i'm not sure about snap or flathub since i haven't used them before. From andre at s-e-a-p.de Thu Oct 8 14:05:14 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Thu, 08 Oct 2020 14:05:14 +0000 Subject: DIP 1030-- Named Arguments--Formal Assessment In-Reply-To: References: Message-ID: On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote: > DIP 1030, "Named Arguments", has been accepted. > > During the assessment, Walter and Atila had a discussion > regarding this particular criticism: > > https://forum.dlang.org/post/mailman.1117.1581368593.31109.digitalmars-d at puremagic.com > > "Named arguments breaks this very important pattern: > > auto wrapper(alias origFun)(Parameters!origFun args) > { > // special sauce > return origFun(args); > }" > > They say that, though it's true that `Parameters!func` will not > work in a wrapper, it "doesn't really work now"---default > arguments and storage classes must be accounted for. This can > be done with string mixins, or using a technique referred to by > Jean-Louis Leroy as "refraction", both of which are clumsy. > > So they decided that a new `std.traits` template and a > corresponding `__traits` option are needed which expand into > the exact function signature of another function. > > They also acknowledge that when an API's parameter names > change, code depending on the old parameter names will break. > Struct literals have the same problem and no one complains (the > same is true for C99). And in any case, when such a change > occurs, it's a hard failure as any code using named arguments > with the old parameter names will fail to compile, making it > easy to see how to resolve the issue. Given this, they find the > benefits of the feature outweigh the potential for such > breakage. Hi, how to this new feature interact with opDispatch? Will there be any possibility to extract the argument names in opDispatch? If yes, this "might" increase the usability of pyd: auto df = pd.DataFrame.unpack_call( py(tuple()), py(tuple!("data", "columns")(numpyArray, py(["a", "b"])))); vs. auto df = pd.DataFrame(data=numpyArray, columns=["a", "b"]); Kind regards Andr? From ilyayaroshenko at gmail.com Thu Oct 8 16:40:01 2020 From: ilyayaroshenko at gmail.com (9il) Date: Thu, 08 Oct 2020 16:40:01 +0000 Subject: mir-stat Message-ID: It is a pleasure to announce the Dlang Statistical Package by John Michael Hall. API http://mir-stat.libmir.org/ GitHub http://github.com/libmir/mir-stat DUB https://code.dlang.org/packages/mir-stat The initial release provides descriptive statistics and algorithms for transforming data that are useful in statistical applications. The very basic stuff like `gmean` [1] is located in the mir-algorithm package, it will be downloaded automatically. The generation of random numbers of various distributions is provided by mir-random package [2]. --- libmir.org infrastructure supports cross-site links now. New documentation macro set: GREF GREF1 GREF_ALTTEXT GREF1_ALTTEXT The G* macros add an argument to the first position that should refer to the mir package name. Example: /++ Module header Macros: NDSLICEREF = $(GREF_ALTTEXT mir-algorithm, $(TT $2), $2, mir, ndslice, $1)$(NBSP) +/ /++ See_also: $(NDSLICEREF slice, Slice) +/ Slice!(double, 2) eye(size_t n); --- Have a good day! Ilya [1] http://mir-algorithm.libmir.org/mir_math_stat.html [2] http://mir-random.libmir.org/mir_random_variable.html From andre at s-e-a-p.de Thu Oct 8 17:53:53 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Thu, 08 Oct 2020 17:53:53 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Thursday, 8 October 2020 at 16:40:01 UTC, 9il wrote: > It is a pleasure to announce the Dlang Statistical Package by > John Michael Hall. > > [...] Thanks for this great piece of software. Does Mir provides s.th. similar like Pandas DataFrame, especially the feature to give columns a name and marking as inde x columns? Kind regards Andre From john.michael.hall at gmail.com Thu Oct 8 18:17:30 2020 From: john.michael.hall at gmail.com (jmh530) Date: Thu, 08 Oct 2020 18:17:30 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Thursday, 8 October 2020 at 17:53:53 UTC, Andre Pany wrote: > [snip] > > Thanks for this great piece of software. Does Mir provides > s.th. similar like Pandas DataFrame, especially the feature to > give columns a name and marking as inde x columns? > > Kind regards > Andre Magpie [1] was an initial effort as a summer of code project. The last commit was September 2019. There is also some basic support in mir (example at [2]). Ilya can speak more about long-term plans for enhancing that. One limitation in mir is that Slice's only allow for the same type throughout. For instance, a Slice!(double*, 1u) is a 1-dimensional slice of doubles. Data frames in R or Pandas DataFrames allow for columns with different types, so for instance you can calculate some summary statistic based on some category (like color). So to really get the same functionality, you need to support slices with heterogeneous types. [1] https://github.com/Kriyszig/magpie [2] https://github.com/libmir/mir-algorithm/blob/f30ccd9f7abc63166c9179e04b2817bf656764bd/source/mir/ndslice/allocation.d#L330 From andre at s-e-a-p.de Thu Oct 8 19:33:53 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Thu, 08 Oct 2020 19:33:53 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Thursday, 8 October 2020 at 18:17:30 UTC, jmh530 wrote: > On Thursday, 8 October 2020 at 17:53:53 UTC, Andre Pany wrote: >> [snip] >> >> Thanks for this great piece of software. Does Mir provides >> s.th. similar like Pandas DataFrame, especially the feature to >> give columns a name and marking as inde x columns? >> >> Kind regards >> Andre > > Magpie [1] was an initial effort as a summer of code project. > The last commit was September 2019. > > There is also some basic support in mir (example at [2]). Ilya > can speak more about long-term plans for enhancing that. > > One limitation in mir is that Slice's only allow for the same > type throughout. For instance, a Slice!(double*, 1u) is a > 1-dimensional slice of doubles. Data frames in R or Pandas > DataFrames allow for columns with different types, so for > instance you can calculate some summary statistic based on some > category (like color). So to really get the same functionality, > you need to support slices with heterogeneous types. > > [1] https://github.com/Kriyszig/magpie > [2] > https://github.com/libmir/mir-algorithm/blob/f30ccd9f7abc63166c9179e04b2817bf656764bd/source/mir/ndslice/allocation.d#L330 Thanks for these info. Magpie looks huge and really useful. I will give it a try. I am also highly interested in the long term plans of Mir, as you explained the current limitations. Still in my scenario it is always the same type. A 2d array of doubles, read from parquet files, transformed and written into a new parquet file. Kind regards Andre From james.blachly at gmail.com Thu Oct 8 22:21:27 2020 From: james.blachly at gmail.com (James Blachly) Date: Thu, 8 Oct 2020 18:21:27 -0400 Subject: mir-stat In-Reply-To: References: Message-ID: On 10/8/20 12:40 PM, 9il wrote: > It is a pleasure to announce the Dlang Statistical Package by John > Michael Hall. > > API > http://mir-stat.libmir.org/ > > GitHub > http://github.com/libmir/mir-stat > > DUB > https://code.dlang.org/packages/mir-stat > > The initial release provides descriptive statistics and algorithms for > transforming data that are useful in statistical applications. > > The very basic stuff like `gmean` [1] is located in the mir-algorithm > package, it will be downloaded automatically. > > The generation of random numbers of various distributions is provided by > mir-random package [2]. Outstanding work by all involved. Thank you for driving this (and all of mir) forward. We have already found use in our computational biology lab. From mengukagan at gmail.com Sat Oct 10 12:44:39 2020 From: mengukagan at gmail.com (Mengu) Date: Sat, 10 Oct 2020 12:44:39 +0000 Subject: Sociomantic Tsunami now under new community maintainership In-Reply-To: References: Message-ID: On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw wrote: > Hello Everybody, > > Tsunami is a set of core libraries, applications, and tools > that were used at > sociomantic labs/dunnhumby Germany, and have been available as > open-source > software since 2017 under the direction and management of > dunnhumby. > > [...] this is hell of a work. thank you for getting it out and thank you to all the contributors. From tastyminerals at gmail.com Sun Oct 11 10:14:04 2020 From: tastyminerals at gmail.com (tastyminerals) Date: Sun, 11 Oct 2020 10:14:04 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Thursday, 8 October 2020 at 16:40:01 UTC, 9il wrote: > It is a pleasure to announce the Dlang Statistical Package by > John Michael Hall. > > [...] Awesome! Are there any plans to add functions for inferential stats? From zorael at gmail.com Sun Oct 11 15:52:19 2020 From: zorael at gmail.com (Anonymouse) Date: Sun, 11 Oct 2020 15:52:19 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: > Glad to announce D 2.094.0, ? to the 49 contributors. > > This release comes with faster compiler binaries (built with > ldc), direct git dependencies in dub, better type checking of > vectors, and improved template instantiation diagnostics. > > http://dlang.org/download.html > http://dlang.org/changelog/2.094.0.html > > -Martin Binaries took a while to hit Arch repositories, but now they did and I'm immediately pleasantly surprised. 2.093.1: $ time dub build -c dev > Performing "debug" build using dmd for x86_64. > [...] > max memory: 3598 MB 2.094.0: $ time dub build -c dev > Performing "debug" build using dmd for x86_64. > [...] > max memory: 3277 MB Is it because of dmd being built with ldc? From user1234 at 12.de Sun Oct 11 16:07:19 2020 From: user1234 at 12.de (user1234) Date: Sun, 11 Oct 2020 16:07:19 +0000 Subject: Release D 2.094.0 In-Reply-To: References: Message-ID: On Sunday, 11 October 2020 at 15:52:19 UTC, Anonymouse wrote: > On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak > Binaries took a while to hit Arch repositories, but now they > did and I'm immediately pleasantly surprised. > > 2.093.1: > $ time dub build -c dev >> Performing "debug" build using dmd for x86_64. >> [...] >> max memory: 3598 MB > > 2.094.0: > $ time dub build -c dev >> Performing "debug" build using dmd for x86_64. >> [...] >> max memory: 3277 MB > > Is it because of dmd being built with ldc? No. It's because the AST has been optimized. From john.michael.hall at gmail.com Sun Oct 11 17:10:19 2020 From: john.michael.hall at gmail.com (jmh530) Date: Sun, 11 Oct 2020 17:10:19 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Sunday, 11 October 2020 at 10:14:04 UTC, tastyminerals wrote: > On Thursday, 8 October 2020 at 16:40:01 UTC, 9il wrote: >> It is a pleasure to announce the Dlang Statistical Package by >> John Michael Hall. >> >> [...] > > Awesome! Are there any plans to add functions for inferential > stats? Next thing I want to add is histogram (influenced by Boost histogram), but I have been a bit busy lately and haven't finished it. After histogram, the next step would probably be pdfs/cdfs/icdfs, but I was thinking about just borrowing from what is in dstats (I'll need to look into the license compatibility). With those functions in there, then t-test and similar functions would be straightforward. From ilyayaroshenko at gmail.com Sun Oct 11 17:35:26 2020 From: ilyayaroshenko at gmail.com (9il) Date: Sun, 11 Oct 2020 17:35:26 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Sunday, 11 October 2020 at 17:10:19 UTC, jmh530 wrote: > On Sunday, 11 October 2020 at 10:14:04 UTC, tastyminerals wrote: >> On Thursday, 8 October 2020 at 16:40:01 UTC, 9il wrote: >>> It is a pleasure to announce the Dlang Statistical Package by >>> John Michael Hall. >>> >>> [...] >> >> Awesome! Are there any plans to add functions for inferential >> stats? > > Next thing I want to add is histogram (influenced by Boost > histogram), but I have been a bit busy lately and haven't > finished it. After histogram, the next step would probably be > pdfs/cdfs/icdfs, but I was thinking about just borrowing from > what is in dstats (I'll need to look into the license > compatibility). With those functions in there, then t-test and > similar functions would be straightforward. Maybe we should replace Boost with MIT for most of the Mir packages. What do you think? From john.michael.hall at gmail.com Mon Oct 12 00:43:51 2020 From: john.michael.hall at gmail.com (jmh530) Date: Mon, 12 Oct 2020 00:43:51 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Sunday, 11 October 2020 at 17:35:26 UTC, 9il wrote: > [snip] > > Maybe we should replace Boost with MIT for most of the Mir > packages. What do you think? I can't speak to the technical differences between the two. My understanding is that MIT is more permissive than Boost, but MIT always requires the user to include a copy notice and Boost has an exception. Anyway, it looks like the dstats/distrib.d file [1] is based on MathExtra [2] that is based on Cephes [3]. The dstat file looks like it has a 3-part BSD license, while MathExtra is MIT licensed. Cephes seems to be copyrighted. [1] https://github.com/DlangScience/dstats/blob/master/source/dstats/distrib.d [2] http://www.dsource.org/projects/mathextra [3] https://www.netlib.org/cephes/ From karabutaworld at gmail.com Tue Oct 13 07:02:26 2020 From: karabutaworld at gmail.com (aberba) Date: Tue, 13 Oct 2020 07:02:26 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Monday, 12 October 2020 at 00:43:51 UTC, jmh530 wrote: > On Sunday, 11 October 2020 at 17:35:26 UTC, 9il wrote: >> [snip] > I can't speak to the technical differences between the two. My > understanding is that MIT is more permissive than Boost, .... I make all my stuff Boost so that anyone can do whatever they want with the code. So I'm hoe its not that permissive. From code at dawg.eu Tue Oct 13 09:02:09 2020 From: code at dawg.eu (Martin Nowak) Date: Tue, 13 Oct 2020 09:02:09 +0000 Subject: Beta 2.094.1 Message-ID: Glad to announce the first beta for the 2.094.1 point release, ? to the 8 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.094.1.html As usual please report any bugs at https://issues.dlang.org -Martin From john.michael.hall at gmail.com Tue Oct 13 10:30:41 2020 From: john.michael.hall at gmail.com (jmh530) Date: Tue, 13 Oct 2020 10:30:41 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Tuesday, 13 October 2020 at 07:02:26 UTC, aberba wrote: > On Monday, 12 October 2020 at 00:43:51 UTC, jmh530 wrote: >> On Sunday, 11 October 2020 at 17:35:26 UTC, 9il wrote: >>> [snip] > >> I can't speak to the technical differences between the two. My >> understanding is that MIT is more permissive than Boost, .... > > I make all my stuff Boost so that anyone can do whatever they > want with the code. So I'm hoe its not that permissive. Boost says: Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following: MIT says: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The difference is that MIT says you can use it without restriction, including a few things, while Boost says you can do some things. I only meant that MIT license was more permissive in that if there are other things you want to do with it that are not listed on Boost (I don't know what that would be), then MIT would allow it. From schveiguy at gmail.com Tue Oct 13 13:40:29 2020 From: schveiguy at gmail.com (Steven Schveighoffer) Date: Tue, 13 Oct 2020 09:40:29 -0400 Subject: Beerconf Doctoberfest! Message-ID: Yeah, it's trendy to drink beer in October. And they cancelled the real Oktoberfest, so D is here to pick up the slack! Grab some brews (or anything to drink, really), and your favorite D topics, and join us October 24-25th. Someone (probably Iain again) will post a link to the stream on Saturday. Note that the Beerconf for November will coincide with Dconf Online 2020, and will be more "official" than this. I expect some news to come out about that soon. -Steve From aldacron at gmail.com Wed Oct 14 12:41:34 2020 From: aldacron at gmail.com (Mike Parker) Date: Wed, 14 Oct 2020 12:41:34 +0000 Subject: DConf Online 2020 Schedule Message-ID: The DConf Online schedule is now live on the website. I've got a blog post coming tomorrow which will, among other things, include an announcement about the schedule aimed at the world outside our community in a form suitable for /r/programming. https://dconf.org/2020/online/index.html From petitv.isat at gmail.com Wed Oct 14 14:07:39 2020 From: petitv.isat at gmail.com (Ezneh) Date: Wed, 14 Oct 2020 14:07:39 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: > The DConf Online schedule is now live on the website. I've got > a blog post coming tomorrow which will, among other things, > include an announcement about the schedule aimed at the world > outside our community in a form suitable for /r/programming. > > https://dconf.org/2020/online/index.html The schedule and talks are really interesting. Can't wait to see those. I found few typos in the following parts of the text: "D is a multi-paradigm programming language, and one of tho1se paradigms [?]" -> tho1se should be those "Parallelism, message passing concurrency, nested functions, [?]" -> Missing a comma between 'message passing' and 'concurrency'? "In this talk, Mathias will share his recent work and future plans related to two topic that are core to D." -> topics instead of topic From aldacron at gmail.com Wed Oct 14 14:53:23 2020 From: aldacron at gmail.com (Mike Parker) Date: Wed, 14 Oct 2020 14:53:23 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 14:07:39 UTC, Ezneh wrote: > I found few typos in the following parts of the text: > > Thanks! From johan_forsberg_86 at hotmail.com Wed Oct 14 16:36:34 2020 From: johan_forsberg_86 at hotmail.com (Imperatorn) Date: Wed, 14 Oct 2020 16:36:34 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: > The DConf Online schedule is now live on the website. I've got > a blog post coming tomorrow which will, among other things, > include an announcement about the schedule aimed at the world > outside our community in a form suitable for /r/programming. > > https://dconf.org/2020/online/index.html Cool! Looks interesting ? From starcanopy at protonmail.com Wed Oct 14 20:21:53 2020 From: starcanopy at protonmail.com (starcanopy) Date: Wed, 14 Oct 2020 20:21:53 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: > The DConf Online schedule is now live on the website. I've got > a blog post coming tomorrow which will, among other things, > include an announcement about the schedule aimed at the world > outside our community in a form suitable for /r/programming. > > https://dconf.org/2020/online/index.html Appreciate your work, Mike! > Trust Me: An Exploration of @trusted Code in D I am greatly looking forward to this talk. From acehreli at yahoo.com Wed Oct 14 23:15:17 2020 From: acehreli at yahoo.com (=?UTF-8?Q?Ali_=c3=87ehreli?=) Date: Wed, 14 Oct 2020 16:15:17 -0700 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On 10/14/20 7:07 AM, Ezneh wrote: > "Parallelism, message passing concurrency, nested functions, [?]" > -> Missing a comma between 'message passing' and 'concurrency'? It should be "message-passing concurrency" but it's fine with the comma as well. Ali From andrej.mitrovich at gmail.com Thu Oct 15 01:25:44 2020 From: andrej.mitrovich at gmail.com (Andrej Mitrovic) Date: Thu, 15 Oct 2020 01:25:44 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: > The DConf Online schedule is now live on the website. I've got > a blog post coming tomorrow which will, among other things, > include an announcement about the schedule aimed at the world > outside our community in a form suitable for /r/programming. > > https://dconf.org/2020/online/index.html I'm a bit confused about this sentence: The D Language Foundation is very pleased to announce that DConf Online 2020 (not DConf 2020 Online!) is taking place November 21 and 22, 2020. What exactly is the difference between the naming? From acehreli at yahoo.com Thu Oct 15 01:39:37 2020 From: acehreli at yahoo.com (=?UTF-8?Q?Ali_=c3=87ehreli?=) Date: Wed, 14 Oct 2020 18:39:37 -0700 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On 10/14/20 6:25 PM, Andrej Mitrovic wrote: > The D Language Foundation is very pleased to announce that DConf Online > 2020 (not DConf 2020 Online!) is taking place November 21 and 22, 2020. > > What exactly is the difference between the naming? This one is not the online version of DConf that has been canceled this year. We will have two conferences from now on: - May (June?): DConf - November: DConf Online Ali From alynch4047 at gmail.com Thu Oct 15 07:21:36 2020 From: alynch4047 at gmail.com (Abdulhaq) Date: Thu, 15 Oct 2020 07:21:36 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: > The DConf Online schedule is now live on the website. I've got > a blog post coming tomorrow which will, among other things, > include an announcement about the schedule aimed at the world > outside our community in a form suitable for /r/programming. > > https://dconf.org/2020/online/index.html It looks really interesting, thanks and looking forward to it... From aldacron at gmail.com Thu Oct 15 15:05:00 2020 From: aldacron at gmail.com (Mike Parker) Date: Thu, 15 Oct 2020 15:05:00 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: > I've got a blog post coming tomorrow The blog: https://dlang.org/blog/2020/10/15/d-2-094-0-dconf-online-schedule-and-saoc-2020/ Reddit: https://www.reddit.com/r/programming/comments/jbp7j6/d_2094_released/ From n3minis-git at yahoo.es Fri Oct 16 20:29:42 2020 From: n3minis-git at yahoo.es (XavierAP) Date: Fri, 16 Oct 2020 20:29:42 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Thursday, 15 October 2020 at 01:39:37 UTC, Ali ?ehreli wrote: > > This one is not the online version of DConf that has been > canceled this year. We will have two conferences from now on: > > - May (June?): DConf > - November: DConf Online Great to hear, looking forward to every new online conference! From n3minis-git at yahoo.es Fri Oct 16 20:31:07 2020 From: n3minis-git at yahoo.es (XavierAP) Date: Fri, 16 Oct 2020 20:31:07 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: > > https://dconf.org/2020/online/index.html I miss a bit more information how one accesses the DConf. Is it a YouTube live stream or something that will be linked later, it'd be nice to mention it already, and in the meantime link to the channel, or the like. Normally conferences have an option to register your email to get reminders, about the next occurrence as well as next years', keep posted, etc. Anyway I'll write it in my agenda and will see you, thank you! From karabutaworld at gmail.com Sun Oct 18 22:40:53 2020 From: karabutaworld at gmail.com (aberba) Date: Sun, 18 Oct 2020 22:40:53 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Thursday, 1 October 2020 at 18:04:35 UTC, kinke wrote: > Glad to announce the first beta for LDC 1.24: > > - Based on D 2.094.0+. > - Support for LLVM 11. > The prebuilt packages use v11.0.0-rc4+, and the x86 packages > newly include the LLVM backend for AMD GPUs. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.24.0-beta1 > > Please help test, and thanks to all contributors & sponsors! It would be convenient if you provided a .exe installer as well. Not sure what to do with the .7z file without manual tinkering. From destructionator at gmail.com Sun Oct 18 22:47:17 2020 From: destructionator at gmail.com (Adam D. Ruppe) Date: Sun, 18 Oct 2020 22:47:17 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: > Not sure what to do with the .7z file without manual tinkering. You can simply unzip it and use it directly. That's the best way to use most D compilers actually, then any versions can live side by side without affecting each other. From code at dawg.eu Sun Oct 18 22:50:24 2020 From: code at dawg.eu (Martin Nowak) Date: Sun, 18 Oct 2020 22:50:24 +0000 Subject: Release D 2.094.1 Message-ID: Glad to announce D 2.094.1, ? to the 11 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.094.1, see the changelog for more details. http://dlang.org/changelog/2.094.1.html -Martin From karabutaworld at gmail.com Sun Oct 18 23:07:26 2020 From: karabutaworld at gmail.com (aberba) Date: Sun, 18 Oct 2020 23:07:26 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Sunday, 18 October 2020 at 22:47:17 UTC, Adam D. Ruppe wrote: > On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: >> Not sure what to do with the .7z file without manual tinkering. > > You can simply unzip it and use it directly. > > That's the best way to use most D compilers actually, then any > versions can live side by side without affecting each other. It's what I did and added to my system path...but that's if you know what you're doing. An installer just like dmd etc is what newbies are used to. From Bastiaan at Veelo.net Mon Oct 19 13:43:14 2020 From: Bastiaan at Veelo.net (Bastiaan Veelo) Date: Mon, 19 Oct 2020 13:43:14 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Sunday, 18 October 2020 at 23:07:26 UTC, aberba wrote: > On Sunday, 18 October 2020 at 22:47:17 UTC, Adam D. Ruppe wrote: >> On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: >>> Not sure what to do with the .7z file without manual >>> tinkering. >> >> You can simply unzip it and use it directly. >> >> That's the best way to use most D compilers actually, then any >> versions can live side by side without affecting each other. > > It's what I did and added to my system path...but that's if you > know what you're doing. An installer just like dmd etc is what > newbies are used to. I'm not suggesting that this fills the need of newbies, but there is this: https://dlang.org/install.html. --Bastiaan. From destructionator at gmail.com Mon Oct 19 13:59:42 2020 From: destructionator at gmail.com (Adam D. Ruppe) Date: Mon, 19 Oct 2020 13:59:42 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Monday, 19 October 2020 at 13:43:14 UTC, Bastiaan Veelo wrote: > I'm not suggesting that this fills the need of newbies, but > there is this: https://dlang.org/install.html. Nobody should ever follow those terrible instructions, they leave you so fragile in the event of future updates, takes superuser install access, and just generally scatters crap. If anything that page should be marked like "FOR PACKAGE MAINTAINERS ONLY" (even then I wouldn't do it that way but at least that's a kinda valid use case) since no end user should ever mess with that. Just unzip it in place. Maybe add it to your PATH if that's your thing. But don't go scattering files, you'll regret it when it comes update time. From snarwin at gmail.com Mon Oct 19 14:20:02 2020 From: snarwin at gmail.com (Paul Backus) Date: Mon, 19 Oct 2020 14:20:02 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Monday, 19 October 2020 at 13:59:42 UTC, Adam D. Ruppe wrote: > On Monday, 19 October 2020 at 13:43:14 UTC, Bastiaan Veelo > wrote: >> I'm not suggesting that this fills the need of newbies, but >> there is this: https://dlang.org/install.html. > > Nobody should ever follow those terrible instructions, they > leave you so fragile in the event of future updates, takes > superuser install access, and just generally scatters crap. Are we looking at the same instructions? The ones I see at that URL don't require superuser access and install everything to a self-contained directory in the user's $HOME. It's pretty much exactly what you recommend, with a bit of extra automation. From destructionator at gmail.com Mon Oct 19 14:58:37 2020 From: destructionator at gmail.com (Adam D. Ruppe) Date: Mon, 19 Oct 2020 14:58:37 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Monday, 19 October 2020 at 14:20:02 UTC, Paul Backus wrote: > Are we looking at the same instructions? aaaaah i mixed it up with https://dlang.org/dmd-linux.html#installation in my brain without clicking the link :( sorry my bad those are ok. From notna.remove.this at ist-einmalig.de Mon Oct 19 18:48:11 2020 From: notna.remove.this at ist-einmalig.de (notna) Date: Mon, 19 Oct 2020 18:48:11 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: > > It would be convenient if you provided a .exe installer as > well. Not sure what to do with the .7z file without manual > tinkering. use scoop for Windows package mgmt in a user context. build with developers in mind. for installation see: https://scoop.sh/ simple as: * scoop install dmd * scoop install ldc stay always up to date: * scoop update * scoop update * ... and MUCH more, see https://github.com/lukesampson/scoop/wiki From andre at s-e-a-p.de Mon Oct 19 20:49:14 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Mon, 19 Oct 2020 20:49:14 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Monday, 19 October 2020 at 18:48:11 UTC, notna wrote: > On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: >> >> It would be convenient if you provided a .exe installer as >> well. Not sure what to do with the .7z file without manual >> tinkering. > > use scoop for Windows package mgmt in a user context. build > with developers in mind. for installation see: > https://scoop.sh/ > > simple as: > * scoop install dmd > * scoop install ldc > > stay always up to date: > * scoop update > * scoop update * > > ... and MUCH more, see https://github.com/lukesampson/scoop/wiki Also Microsoft is working on a package manager which might be an option in the future https://docs.microsoft.com/de-de/windows/package-manager/ Kind regards Andre From b2.temp at gmx.com Tue Oct 20 10:40:54 2020 From: b2.temp at gmx.com (Basile B.) Date: Tue, 20 Oct 2020 10:40:54 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Monday, 19 October 2020 at 20:49:14 UTC, Andre Pany wrote: > On Monday, 19 October 2020 at 18:48:11 UTC, notna wrote: >> On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: >>> >>> It would be convenient if you provided a .exe installer as >>> well. Not sure what to do with the .7z file without manual >>> tinkering. >> >> use scoop for Windows package mgmt in a user context. build >> with developers in mind. for installation see: >> https://scoop.sh/ >> >> simple as: >> * scoop install dmd >> * scoop install ldc >> >> stay always up to date: >> * scoop update >> * scoop update * >> >> ... and MUCH more, see >> https://github.com/lukesampson/scoop/wiki > > Also Microsoft is working on a package manager which might be > an option in the future > https://docs.microsoft.com/de-de/windows/package-manager/ > > Kind regards > Andre Looks a bit like "classic MS". Instead of buying something similar that exists they do their own. From karabutaworld at gmail.com Tue Oct 20 16:08:47 2020 From: karabutaworld at gmail.com (aberba) Date: Tue, 20 Oct 2020 16:08:47 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Monday, 19 October 2020 at 18:48:11 UTC, notna wrote: > On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: >> >> It would be convenient if you provided a .exe installer as >> well. Not sure what to do with the .7z file without manual >> tinkering. > > use scoop for Windows package mgmt in a user context. build > with developers in mind. for installation see: > https://scoop.sh/ > > simple as: > * scoop install dmd > * scoop install ldc > > stay always up to date: > * scoop update > * scoop update * > > ... and MUCH more, see https://github.com/lukesampson/scoop/wiki It's an option but doesn't fill the need for an installer. Not sure why its hasn't been done. From karabutaworld at gmail.com Tue Oct 20 16:11:24 2020 From: karabutaworld at gmail.com (aberba) Date: Tue, 20 Oct 2020 16:11:24 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Monday, 19 October 2020 at 20:49:14 UTC, Andre Pany wrote: > On Monday, 19 October 2020 at 18:48:11 UTC, notna wrote: >> On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: >>> >>> It would be convenient if you provided a .exe installer as >>> well. Not sure what to do with the .7z file without manual >>> tinkering. >> >> use scoop for Windows package mgmt in a user context. build >> with developers in mind. for installation see: >> https://scoop.sh/ >> >> simple as: >> * scoop install dmd >> * scoop install ldc >> >> stay always up to date: >> * scoop update >> * scoop update * >> >> ... and MUCH more, see >> https://github.com/lukesampson/scoop/wiki > > Also Microsoft is working on a package manager which might be > an option in the future > https://docs.microsoft.com/de-de/windows/package-manager/ > > Kind regards > Andre Yes, I have it (winget) installed. Still, the absence of an exe means its more convenient to just use DMD. Unfortunately some dev have decided to not get their stuff to work on DMD. DMD is an easy get-go. No thinkering needed. From noone at nowhere.com Tue Oct 20 17:36:11 2020 From: noone at nowhere.com (kinke) Date: Tue, 20 Oct 2020 17:36:11 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Tuesday, 20 October 2020 at 16:08:47 UTC, aberba wrote: > It's an option but doesn't fill the need for an installer. Not > sure why its hasn't been done. See https://github.com/ldc-developers/ldc/issues/1754. I personally never download the DMD installers, only the .7z. I also don't use a global PATH set up to point to a particular LDC installation. I expect the vast majority of Windows *devs* to prefer a simple download&unpack over some installer. Those wanting to click through setup steps can use the VisualD installer with bundled LDC. From john.michael.hall at gmail.com Tue Oct 20 18:12:14 2020 From: john.michael.hall at gmail.com (jmh530) Date: Tue, 20 Oct 2020 18:12:14 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote: > [snip] > > See https://github.com/ldc-developers/ldc/issues/1754. I > personally never download the DMD installers, only the .7z. I > also don't use a global PATH set up to point to a particular > LDC installation. I expect the vast majority of Windows *devs* > to prefer a simple download&unpack over some installer. Those > wanting to click through setup steps can use the VisualD > installer with bundled LDC. I'm sympathetic to Ilya's concerns in that thread, but it would help to get empirical. What about a calculation of the number of unique downloads for DMD's Windows installer vs. those who download the .7z? The .7z probably has more downloads for CIs, but I wouldn't be surprised if there is a larger share of people downloading the DMD installer than you think. I also have a PATH set up to point to a particular LDC installation that I need to update whenever I upgrade LDC. It has caused me problems in the past when I forget to change it... I don't recall ever using the VisualD installer to install LDC. From karabutaworld at gmail.com Tue Oct 20 20:09:58 2020 From: karabutaworld at gmail.com (aberba) Date: Tue, 20 Oct 2020 20:09:58 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote: > On Tuesday, 20 October 2020 at 16:08:47 UTC, aberba wrote: >> It's an option but doesn't fill the need for an installer. Not >> sure why its hasn't been done. > > See https://github.com/ldc-developers/ldc/issues/1754. I > personally never download the DMD installers, only the .7z. I > also don't use a global PATH set up to point to a particular > LDC installation. I expect the vast majority of Windows *devs* > to prefer a simple download&unpack over some installer. Those > wanting to click through setup steps can use the VisualD > installer with bundled LDC. Supposing I'm new to D, I have previous experience with LLVM-based compilers so I prefer to use LDC. How am I supposed to know what to do? Where is the information on how to get it on my system through visualD installer? The LDC experience needs some improvement here. From karabutaworld at gmail.com Tue Oct 20 20:21:56 2020 From: karabutaworld at gmail.com (aberba) Date: Tue, 20 Oct 2020 20:21:56 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote: > On Tuesday, 20 October 2020 at 16:08:47 UTC, aberba wrote: >> It's an option but doesn't fill the need for an installer. Not >> sure why its hasn't been done. > > See https://github.com/ldc-developers/ldc/issues/1754. From the discussions, it seems you still don't see the value of an installer...backing it with the idea that LDC is for "developers". I'm a developer myself and I use installers all the time when on Windows...there are very few people I personally know who would go for an archive file to set it up themselves. So not everyone is like you. The reason why I personally go for DMD over LDC is convenience (especially when introducing D to newbies)...even though LDC is more optimized for performance. Unless what you guys are doing is an artificial barrier to get others to not use it. From j at j.nl Tue Oct 20 21:58:16 2020 From: j at j.nl (Johan Engelen) Date: Tue, 20 Oct 2020 21:58:16 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Tuesday, 20 October 2020 at 20:21:56 UTC, aberba wrote: > On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote: >> On Tuesday, 20 October 2020 at 16:08:47 UTC, aberba wrote: >>> It's an option but doesn't fill the need for an installer. >>> Not sure why its hasn't been done. >> >> See https://github.com/ldc-developers/ldc/issues/1754. > > From the discussions, it seems you still don't see the value of > an installer...backing it with the idea that LDC is for > "developers". I'm a developer myself and I use installers all > the time when on Windows...there are very few people I > personally know who would go for an archive file to set it up > themselves. > > So not everyone is like you. The reason why I personally go for > DMD over LDC is convenience (especially when introducing D to > newbies)...even though LDC is more optimized for performance. > > Unless what you guys are doing is an artificial barrier to get > others to not use it. Guys, all points have been made, there is no wrong and right here, let's stop arguing over this. What is needed is someone who thinks it is useful to have an exe installer and wants to do the work. It cannot be done by someone who thinks it is not useful, because there are decisions to be made (like which folder to install it in, whether to overwrite old or not), that can only be made by someone who actually cares about it. There is no point in trying to convince kinke or me. I'm sure noone will be against uploading the installer exe onto github release page once it's been made and checked. -Johan From john.michael.hall at gmail.com Tue Oct 20 22:08:08 2020 From: john.michael.hall at gmail.com (jmh530) Date: Tue, 20 Oct 2020 22:08:08 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Tuesday, 20 October 2020 at 21:58:16 UTC, Johan Engelen wrote: > On Tuesday, 20 October 2020 at 20:21:56 UTC, aberba wrote: >> [...] > > Guys, all points have been made, there is no wrong and right > here, let's stop arguing over this. > > What is needed is someone who thinks it is useful to have an > exe installer and wants to do the work. It cannot be done by > someone who thinks it is not useful, because there are > decisions to be made (like which folder to install it in, > whether to overwrite old or not), that can only be made by > someone who actually cares about it. There is no point in > trying to convince kinke or me. > > I'm sure noone will be against uploading the installer exe onto > github release page once it's been made and checked. > > -Johan Someone who wants to take it on could modify the DMD one https://github.com/dlang/installer/blob/master/windows/ It looks like it uses NSIS. From rburners at gmail.com Wed Oct 21 14:47:14 2020 From: rburners at gmail.com (Robert burner Schadek) Date: Wed, 21 Oct 2020 14:47:14 +0000 Subject: Computing the next SemVer for dlang packages with dsemver Message-ID: https://code.dlang.org/packages/dsemver is a program that computes the next SemVer for your dlang package. It uses a slightly modified SemVer definition. It does this by using the -X flag for dmd to get a json file of the symbols and then compares them to the most recent git tag that resembles a SemVer. First release is 1.0.0. If a symbol is removed or its signature changed the major version is increment and the minor and the bugfix number reset to 0. If a new symbol is added, the minor number is incremented and the bug fix number is set to 0. If all symbol stay the same the bugfix number is incremented. In an ideal world the dub registry would use this to compute the SemVer for you, but baby steps. I hope to see many bug reports and PRs. From sludwig at outerproduct.org Wed Oct 21 15:27:46 2020 From: sludwig at outerproduct.org (=?UTF-8?Q?S=c3=b6nke_Ludwig?=) Date: Wed, 21 Oct 2020 17:27:46 +0200 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: Am 21.10.2020 um 16:47 schrieb Robert burner Schadek: > https://code.dlang.org/packages/dsemver > > is a program that computes the next SemVer for your dlang package. > > It uses a slightly modified SemVer definition. > > It does this by using the -X flag for dmd to get a json file of the symbols > and then compares them to the most recent git tag that resembles a SemVer. > > First release is 1.0.0. > If a symbol is removed or its signature changed the major version is > increment > and the minor and the bugfix number reset to 0. > If a new symbol is added, the minor number is incremented and the bug fix > number is set to 0. > If all symbol stay the same the bugfix number is incremented. > > In an ideal world the dub registry would use this to compute the SemVer > for you, > but baby steps. > > I hope to see many bug reports and PRs. There are cases where a symbol change is not a breaking change in practice (maybe splitting up a function into two separate overloads) and where no symbol change is required to produce a real breaking change (e.g. a compile-time logic change within some template). In my experience it is often a judgement call where to draw the line, even sometimes deciding between a patch release and a major release. Of course, theoretically *any* change that is not backed by a preexisting specification is a breaking change in one way or another, especially when D's introspection or runtime behavior come into play... Anyway, I think this can be a very useful diagnostic tool to avoid accidental introduction of breaking changes at that level, and maybe also to actually generate new versions in certain contexts. However, I definitely don't see this as a potential feature of the registry in the sense that it automatically creates new versions for all packages. From rburners at gmail.com Wed Oct 21 15:34:38 2020 From: rburners at gmail.com (Robert burner Schadek) Date: Wed, 21 Oct 2020 15:34:38 +0000 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: On Wednesday, 21 October 2020 at 15:27:46 UTC, S?nke Ludwig wrote: > However, I definitely don't see this as a potential feature of > the registry in the sense that it automatically creates new > versions for all packages. That is why I said in an ideal world and baby steps. Also, dsemver does not call git yet to create the new tag. From first.name at gafam.com Wed Oct 21 15:41:47 2020 From: first.name at gafam.com (Guillaume Piolat) Date: Wed, 21 Oct 2020 15:41:47 +0000 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: On Wednesday, 21 October 2020 at 14:47:14 UTC, Robert burner Schadek wrote: > Semantic versioning is useful, but 0.x.x versioning is a > pointless loophole. When a piece of D software is published, > and it is published if other people can find it on dub, it is > released. And released means 1.0.0 at least. Agree. Or we won't ever have a dependable ecosystem. Please provide guarantees. Success of D is success of building upon the ecosystem of libraries. Something that people must consider to avoid too much major version tags is: - delay breaking changes and pack the breaking change at once - **have a small (and agreeable) public API surface**, use private and package identifier that are allowed to change spec - provide a changelog to go from a major to another major tag, no one want to read your git commits - a system of option using `version` identifier to make something similar to DMDFE's -preview. Configuration to gain compat at the expense of simplicity (option count can grow wildly). From rburners at gmail.com Wed Oct 21 15:49:56 2020 From: rburners at gmail.com (Robert burner Schadek) Date: Wed, 21 Oct 2020 15:49:56 +0000 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: On Wednesday, 21 October 2020 at 15:27:46 UTC, S?nke Ludwig wrote: To really get it correct properly most of dmd is needed anyway. But this might a good first step to get out under the 0.x.x rug we are currently in and a lot closer to actual meaning in the semver of a lib on code.dlang.org From sludwig at outerproduct.org Wed Oct 21 17:55:00 2020 From: sludwig at outerproduct.org (=?UTF-8?Q?S=c3=b6nke_Ludwig?=) Date: Wed, 21 Oct 2020 19:55:00 +0200 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: Am 21.10.2020 um 17:41 schrieb Guillaume Piolat: > On Wednesday, 21 October 2020 at 14:47:14 UTC, Robert burner Schadek wrote: >> Semantic versioning is useful, but 0.x.x versioning is a pointless >> loophole. When a piece of D software is published, and it is published >> if other people can find it on dub, it is released. And released means >> 1.0.0 at least. > > Agree. Or we won't ever have a dependable ecosystem. Please provide > guarantees. > Success of D is success of building upon the ecosystem of libraries. > > Something that people must consider to avoid too much major version tags > is: > - delay breaking changes and pack the breaking change at once > - **have a small (and agreeable) public API surface**, use private and > package identifier that are allowed to change spec > - provide a changelog to go from a major to another major tag, no one > want to read your git commits > - a system of option using `version` identifier to make something > similar to DMDFE's -preview. Configuration to gain compat at the expense > of simplicity (option count can grow wildly). 0.x.y vs. 1+.x.y is about the development process/state. Quite often a design is not yet fully fleshed out in the beginning and there are many incremental changes to the API. If 0.x.y didn't exist, that would simply mean that either the project gets more or less stuck with the initial (bad) design, or that it quickly increments major versions, effectively providing no more stability as in the 0.x.y case. But otherwise I agree, there are definitely quite a few projects that are beyond this stage and should make the jump to 1.0.0 (a few of mine included). From sludwig at outerproduct.org Wed Oct 21 17:58:53 2020 From: sludwig at outerproduct.org (=?UTF-8?Q?S=c3=b6nke_Ludwig?=) Date: Wed, 21 Oct 2020 19:58:53 +0200 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: Am 21.10.2020 um 17:34 schrieb Robert burner Schadek: > On Wednesday, 21 October 2020 at 15:27:46 UTC, S?nke Ludwig wrote: > >> However, I definitely don't see this as a potential feature of the >> registry in the sense that it automatically creates new versions for >> all packages. > > That is why I said in an ideal world and baby steps. The thing is just that I don't think it is possible to find a set of rules that always work. There will always be something that should "obviously" be flagged as a breaking change and something that is extremely annoying to be detected as such (forcing a major version increment). But as some kind of warning/hint and with some kind of integration into the version tagging process (maybe forcing a manual version release on the registry after warnings come up) it could definitely be really nice. > > Also, dsemver does not call git yet to create the new tag. From rburners at gmail.com Thu Oct 22 08:59:18 2020 From: rburners at gmail.com (Robert burner Schadek) Date: Thu, 22 Oct 2020 08:59:18 +0000 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: On Wednesday, 21 October 2020 at 17:55:00 UTC, S?nke Ludwig wrote: > 0.x.y vs. 1+.x.y is about the development process/state. Quite > often a design is not yet fully fleshed out in the beginning > and there are many incremental changes to the API. If 0.x.y > didn't exist, that would simply mean that either the project > gets more or less stuck with the initial (bad) design, or that > it quickly increments major versions, effectively providing no > more stability as in the 0.x.y case. I think that is the one mistake SemVer does. 0.x.y is just one big loophole. After the 1.x.y release an breaking api change requires a major version increment. The way it should be. Stability or unstable is only mentioned in the 0.x.y definitions. You are not stuck on a bad design, break the api, improve the api, increment the major version number. If you break the api in an 0.x.y version the hard part does not change. In both instances the users have to update their usage. In know in theory 0.x.y should be considered unstable. But by amount of 0.x.y we have you pretty much can't get anything done in D if you only use stable packages. The loophole has become the normal case. So what can we do, I see two major options: 1. we can live on the edge and use unstable packages and have no meaning in the SemVer number 2. we can acknowledge that most of them are stable, put a 1. in front and ignore the 0.x.y part of the SemVer definition and have the SemVer mean something dsemver does 2. And true there might be cases where dsemver does not increment the number correctly, but you can always increment by hand. Also if your api is not stable after your 1.x.y release and you break everything in 2.x.y, so what. Your users are also annoyed when you break your api from 0.1.x to 0.1.1. Only difference is they could have seen in coming by looking at the SemVer. I should stop ranting now. From rburners at gmail.com Thu Oct 22 09:07:26 2020 From: rburners at gmail.com (Robert burner Schadek) Date: Thu, 22 Oct 2020 09:07:26 +0000 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: On Wednesday, 21 October 2020 at 17:58:53 UTC, S?nke Ludwig wrote: > The thing is just that I don't think it is possible to find a > set of rules that always work. There will always be something > that should "obviously" be flagged as a breaking change and > something that is extremely annoying to be detected as such > (forcing a major version increment). True, but if we can get 90% of the way there by a tool we would be a lot better of then where we are today. You should always be able to increment the SemVer by hand. > > But as some kind of warning/hint and with some kind of > integration into the version tagging process (maybe forcing a > manual version release on the registry after warnings come up) > it could definitely be really nice. I'm thinking of a service that gives you a batch that shows you next SemVer of the master branch, as a start. From mail at skoppe.eu Thu Oct 22 11:43:29 2020 From: mail at skoppe.eu (Sebastiaan Koppe) Date: Thu, 22 Oct 2020 11:43:29 +0000 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: On Thursday, 22 October 2020 at 08:59:18 UTC, Robert burner Schadek wrote: > I should stop ranting now. Not at all, I love it. Nice project. From john.loughran.colvin at gmail.com Thu Oct 22 11:48:31 2020 From: john.loughran.colvin at gmail.com (John Colvin) Date: Thu, 22 Oct 2020 11:48:31 +0000 Subject: Highlight general point about software dev and design in general. In-Reply-To: References: Message-ID: On Tuesday, 20 October 2020 at 21:58:16 UTC, Johan Engelen wrote: > On Tuesday, 20 October 2020 at 20:21:56 UTC, aberba wrote: >> On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote: >>> On Tuesday, 20 October 2020 at 16:08:47 UTC, aberba wrote: >>>> It's an option but doesn't fill the need for an installer. >>>> Not sure why its hasn't been done. >>> >>> See https://github.com/ldc-developers/ldc/issues/1754. >> >> From the discussions, it seems you still don't see the value >> of an installer...backing it with the idea that LDC is for >> "developers". I'm a developer myself and I use installers all >> the time when on Windows...there are very few people I >> personally know who would go for an archive file to set it up >> themselves. >> >> So not everyone is like you. The reason why I personally go >> for DMD over LDC is convenience (especially when introducing D >> to newbies)...even though LDC is more optimized for >> performance. >> >> Unless what you guys are doing is an artificial barrier to get >> others to not use it. > > Guys, all points have been made, there is no wrong and right > here, let's stop arguing over this. > > What is needed is someone who thinks it is useful to have an > exe installer and wants to do the work. It cannot be done by > someone who thinks it is not useful, because there are > decisions to be made (like which folder to install it in, > whether to overwrite old or not), that can only be made by > someone who actually cares about it. There is no point in > trying to convince kinke or me. > > I'm sure noone will be against uploading the installer exe onto > github release page once it's been made and checked. > > -Johan Johan hits an important nail right on the head here. While it is possible to design for others who are unlike you, it's much harder than designing for yourself or those who have similar values and priorities w.r.t. the thing in question. A lot of talk about "we (and by we I mean you) should do this thing I think is important" isn't pushing in the most productive direction, because _*_*_{ even if one becomes convinced that there is value in something, that does not mean one has the relevant understanding necessary for good design of that thing }_*_*_ Either the person with the problem works on understanding the tools to fix the problem, or the person with the tools works on understanding the problem. When values and "user experience" and "ease of use" are in play, I think the latter usually gets harder than normal, because understanding what will be easy or pleasing for others who are unlike us is not something everyone is good at.* This shifts the balance towards preferring the former approach where the person with the problem works towards doing at least a significant part of the design.** There will always be other considerations of course, this is just one force out of many. This is not to say that developers shouldn't be thoughtful about their users - they definitely should be - but that doing a good job of that when the users are unlike the developer is _hard_. * Perhaps in practice that ability is negatively associated with a strong sense of personal taste, e.g. great musicians writing the music _they_ want, not trying to specifically please people; the magic isn't that they understand other people, it's that their particular tastes resonate with others strongly. Maybe truly great mass-market businesses come from people who both have that magic _and_ a strong ability to experience their work from other's perspectives, the combination being rare and the ability to integrate the two effectively being even rarer (Steve Jobs comes to mind). ** Design and implementation often don't separate very cleanly in practice, so this probably means implementing it too, at least to proof-of-concept quality. From sludwig at outerproduct.org Thu Oct 22 15:50:45 2020 From: sludwig at outerproduct.org (=?UTF-8?Q?S=c3=b6nke_Ludwig?=) Date: Thu, 22 Oct 2020 17:50:45 +0200 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: Am 22.10.2020 um 10:59 schrieb Robert burner Schadek: > On Wednesday, 21 October 2020 at 17:55:00 UTC, S?nke Ludwig wrote: > >> 0.x.y vs. 1+.x.y is about the development process/state. Quite often a >> design is not yet fully fleshed out in the beginning and there are >> many incremental changes to the API. If 0.x.y didn't exist, that would >> simply mean that either the project gets more or less stuck with the >> initial (bad) design, or that it quickly increments major versions, >> effectively providing no more stability as in the 0.x.y case. > > I think that is the one mistake SemVer does. 0.x.y is just one big > loophole. > After the 1.x.y release an breaking api change requires a major version > increment. > The way it should be. Stability or unstable is only mentioned in the 0.x.y > definitions. > > You are not stuck on a bad design, break the api, improve the api, > increment the major version number. > If you break the api in an 0.x.y version the hard part does not change. > In both instances the users have to update their usage. > > In know in theory 0.x.y should be considered unstable. But by amount of > 0.x.y we have you pretty much can't get anything done in D if you only > use stable packages. > The loophole has become the normal case. > > So what can we do, I see two major options: > 1. we can live on the edge and use unstable packages and have no meaning > in the > ?? SemVer number > 2. we can acknowledge that most of them are stable, put a 1. in front > and ignore > ?? the 0.x.y part of the SemVer definition and have the SemVer mean > something > > dsemver does 2. > > And true there might be cases where dsemver does not increment the > number correctly, but you can always increment by hand. > > Also if your api is not stable after your 1.x.y release and you break > everything in 2.x.y, so what. Your users are also annoyed when you break > your api from 0.1.x to 0.1.1. Only difference is they could have seen in > coming by looking at the SemVer. > > I should stop ranting now. > The real alternative to 0.x.y is 1.0.0-alpha.1+, though, with the drawback that there is no supported means to still provide something like a distinction between breaking (x) and non-breaking (y) changes. There is also value in having some kind of indicator that the code has reached a certain level of maturity (1.0.0). From sludwig at outerproduct.org Thu Oct 22 15:52:46 2020 From: sludwig at outerproduct.org (=?UTF-8?Q?S=c3=b6nke_Ludwig?=) Date: Thu, 22 Oct 2020 17:52:46 +0200 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: Am 22.10.2020 um 17:50 schrieb S?nke Ludwig: > with the drawback that there is no supported means to still provide > something like a distinction between breaking (x) and non-breaking (y) > changes. * with supported I mean that you can use `~>0.x.y` to restrict to a certain x, which would be less obvious for something like 1.0.0-alpha.x.y. From james.blachly at gmail.com Fri Oct 23 14:16:57 2020 From: james.blachly at gmail.com (James Blachly) Date: Fri, 23 Oct 2020 10:16:57 -0400 Subject: Computing the next SemVer for dlang packages with dsemver In-Reply-To: References: Message-ID: On 10/21/20 10:47 AM, Robert burner Schadek wrote: > https://code.dlang.org/packages/dsemver > > is a program that computes the next SemVer for your dlang package. > As indicated downthread, this could be a great ecosystem partner with dmd-as-a-library. Thank you Robert! From spam at here.lot Fri Oct 23 18:01:19 2020 From: spam at here.lot (Kagamin) Date: Fri, 23 Oct 2020 18:01:19 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Tuesday, 20 October 2020 at 20:09:58 UTC, aberba wrote: > Supposing I'm new to D, I have previous experience with > LLVM-based compilers so I prefer to use LDC. How am I supposed > to know what to do? Where is the information on how to get it > on my system through visualD installer? > > The LDC experience needs some improvement here. Supposedly they will want an IDE with everything included in one installer, like Visual Studio, and that's what VisualD installer apparently does. From karabutaworld at gmail.com Fri Oct 23 20:21:39 2020 From: karabutaworld at gmail.com (aberba) Date: Fri, 23 Oct 2020 20:21:39 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Friday, 23 October 2020 at 18:01:19 UTC, Kagamin wrote: > On Tuesday, 20 October 2020 at 20:09:58 UTC, aberba wrote: >> Supposing I'm new to D, I have previous experience with >> LLVM-based compilers so I prefer to use LDC. How am I supposed >> to know what to do? Where is the information on how to get it >> on my system through visualD installer? >> >> The LDC experience needs some improvement here. > > Supposedly they will want an IDE with everything included in > one installer, like Visual Studio, and that's what VisualD > installer apparently does. Not saying Kinke SHOULD do it. Was rather disagreeing with the idea that "developers" don't use installers. And that's a shortcoming with the LDC project...no straightforward way to set it up on Windows using an installer. If visuald supports LDC, why not point people to it. LDC at its current state is a small fraction of DMD, why? Convenience. That's the core difference. And convenience sells. And this is only a Windows problem ( started using Windows few weeks ago and now seeing devs don't provide an installer). Now someone is going to tell me as always (I think its already said) to go do it myself. I don't really see it as a priority for me ATM as I know how to do without an installer. But just know that all successful languages have Windows installers I've found the need to use or try. Those that don't are niche and not ready for mass adoption simple because it easier to use something else that hacking your way out of a first impression. Of course we have DMD. Beginners, if you want an LDC installer then "Go do it yourself". I wouldn't consider that a good message. From no at spam.net Fri Oct 23 20:53:34 2020 From: no at spam.net (bachmeier) Date: Fri, 23 Oct 2020 20:53:34 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Friday, 23 October 2020 at 20:21:39 UTC, aberba wrote: > Beginners, if you want an LDC installer then "Go do it > yourself". I wouldn't consider that a good message. Out of curiosity, what is the alternative message? Someone has to do it. This is a volunteer project, not a business, so there's not a manager that can put a couple guys on it. From johan_forsberg_86 at hotmail.com Fri Oct 23 22:48:33 2020 From: johan_forsberg_86 at hotmail.com (Imperatorn) Date: Fri, 23 Oct 2020 22:48:33 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Friday, 23 October 2020 at 20:21:39 UTC, aberba wrote: > On Friday, 23 October 2020 at 18:01:19 UTC, Kagamin wrote: >> [...] > > Not saying Kinke SHOULD do it. Was rather disagreeing with the > idea that "developers" don't use installers. And that's a > shortcoming with the LDC project...no straightforward way to > set it up on Windows using an installer. If visuald supports > LDC, why not point people to it. > > [...] I agree with this. Not providing an installer gives the message that you're not that interested in people using it. If I have the time later I can try to fix an installer. From starcanopy at protonmail.com Sat Oct 24 00:00:02 2020 From: starcanopy at protonmail.com (starcanopy) Date: Sat, 24 Oct 2020 00:00:02 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Friday, 23 October 2020 at 22:48:33 UTC, Imperatorn wrote: > On Friday, 23 October 2020 at 20:21:39 UTC, aberba wrote: >> On Friday, 23 October 2020 at 18:01:19 UTC, Kagamin wrote: >>> [...] >> >> Not saying Kinke SHOULD do it. Was rather disagreeing with the >> idea that "developers" don't use installers. And that's a >> shortcoming with the LDC project...no straightforward way to >> set it up on Windows using an installer. If visuald supports >> LDC, why not point people to it. >> >> [...] > > I agree with this. Not providing an installer gives the message > that you're not that interested in people using it. That's an exaggeration. Every release is accompanied by binaries that one may easily retrieve. Setting up the dependencies is only done once, and if you're a Windows developer, such an environment most likely exists, and you'll likely only have to add the bin to your path. It's my understanding that there are few people regularly working on LDC; allocating (voluntary!) manpower to a nice but non-essential component doesn't seem wise. From schveiguy at yahoo.com Sat Oct 24 03:34:25 2020 From: schveiguy at yahoo.com (Steven Schveighoffer) Date: Sat, 24 Oct 2020 03:34:25 +0000 Subject: Beerconf Doctoberfest! In-Reply-To: References: Message-ID: On Tuesday, 13 October 2020 at 13:40:29 UTC, Steven Schveighoffer wrote: > Yeah, it's trendy to drink beer in October. And they cancelled > the real Oktoberfest, so D is here to pick up the slack! > > Grab some brews (or anything to drink, really), and your > favorite D topics, and join us October 24-25th. Someone > (probably Iain again) will post a link to the stream on > Saturday. > > Note that the Beerconf for November will coincide with Dconf > Online 2020, and will be more "official" than this. I expect > some news to come out about that soon. > Just realized I forgot to remind people about this. It?s happening tomorrow. See you all there! -Steve From johan_forsberg_86 at hotmail.com Sat Oct 24 13:28:43 2020 From: johan_forsberg_86 at hotmail.com (Imperatorn) Date: Sat, 24 Oct 2020 13:28:43 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Saturday, 24 October 2020 at 00:00:02 UTC, starcanopy wrote: > On Friday, 23 October 2020 at 22:48:33 UTC, Imperatorn wrote: >> On Friday, 23 October 2020 at 20:21:39 UTC, aberba wrote: >>> On Friday, 23 October 2020 at 18:01:19 UTC, Kagamin wrote: >>>> [...] >>> >>> Not saying Kinke SHOULD do it. Was rather disagreeing with >>> the idea that "developers" don't use installers. And that's a >>> shortcoming with the LDC project...no straightforward way to >>> set it up on Windows using an installer. If visuald supports >>> LDC, why not point people to it. >>> >>> [...] >> >> I agree with this. Not providing an installer gives the >> message that you're not that interested in people using it. > > That's an exaggeration. Every release is accompanied by > binaries that one may easily retrieve. Setting up the > dependencies is only done once, and if you're a Windows > developer, such an environment most likely exists, and you'll > likely only have to add the bin to your path. It's my > understanding that there are few people regularly working on > LDC; allocating (voluntary!) manpower to a nice but > non-essential component doesn't seem wise. Yes, but if you want to spread D to the world, you might have to lower the effort in using it as much as possible. Ok, I'm comparing to the experience of like top 20 languages, sure. But why not dream big ey? ? From noone at nowhere.com Sat Oct 24 15:11:08 2020 From: noone at nowhere.com (kinke) Date: Sat, 24 Oct 2020 15:11:08 +0000 Subject: LDC 1.24.0 Message-ID: Glad to announce LDC 1.24 - some highlights: - Based on D 2.094.1+. - Support for LLVM 11. The prebuilt packages use v11.0.0, and the x86 packages newly include the LLVM backend for AMD GPUs. - Experimental support for targeting macOS on 64-bit ARM. The macOS package includes prebuilt druntime/Phobos libraries for cross-compilation via `-mtriple=arm64-apple-macos`. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.24.0 Thanks to all contributors & sponsors! From andre at s-e-a-p.de Sat Oct 24 15:28:52 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Sat, 24 Oct 2020 15:28:52 +0000 Subject: LDC 1.24.0 In-Reply-To: References: Message-ID: On Saturday, 24 October 2020 at 15:11:08 UTC, kinke wrote: > Glad to announce LDC 1.24 - some highlights: > > - Based on D 2.094.1+. > - Support for LLVM 11. The prebuilt packages use v11.0.0, and > the x86 packages newly include the LLVM backend for AMD GPUs. > - Experimental support for targeting macOS on 64-bit ARM. The > macOS package includes prebuilt druntime/Phobos libraries for > cross-compilation via `-mtriple=arm64-apple-macos`. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.24.0 > > Thanks to all contributors & sponsors! Thank you for another great release. Kind regards Andre From ibuclaw at gdcproject.org Sat Oct 24 15:50:43 2020 From: ibuclaw at gdcproject.org (Iain Buclaw) Date: Sat, 24 Oct 2020 15:50:43 +0000 Subject: Beerconf Doctoberfest! In-Reply-To: References: Message-ID: On Saturday, 24 October 2020 at 03:34:25 UTC, Steven Schveighoffer wrote: > On Tuesday, 13 October 2020 at 13:40:29 UTC, Steven > Schveighoffer wrote: >> Yeah, it's trendy to drink beer in October. And they cancelled >> the real Oktoberfest, so D is here to pick up the slack! >> >> Grab some brews (or anything to drink, really), and your >> favorite D topics, and join us October 24-25th. Someone >> (probably Iain again) will post a link to the stream on >> Saturday. >> >> Note that the Beerconf for November will coincide with Dconf >> Online 2020, and will be more "official" than this. I expect >> some news to come out about that soon. >> > > Just realized I forgot to remind people about this. It?s > happening tomorrow. See you all there! > > -Steve Hi everyone, For some reason, I thought it was happening next weekend, sorry for that. Now I'm in the correct calendar week, I'm happy to announce that beerconf has started, following the same naming convention as every month. link: https://meet.jit.si/Dlang2020OctoberBeerConf password: -vtemplates=list-instances People usually get confused, so I'll say this now, there is a "bot" in the room, its name is "beerconf" this month. Don't speak to it, you'll be met with stern silence. :-) I'll be joining in about an hour, so hope to see you all soon over the weekend! Iain. From j at j.nl Sat Oct 24 18:28:33 2020 From: j at j.nl (Johan Engelen) Date: Sat, 24 Oct 2020 18:28:33 +0000 Subject: LDC 1.24.0 In-Reply-To: References: Message-ID: On Saturday, 24 October 2020 at 15:11:08 UTC, kinke wrote: > Glad to announce LDC 1.24 - some highlights: > > - Based on D 2.094.1+. > - Support for LLVM 11. The prebuilt packages use v11.0.0, and > the x86 packages newly include the LLVM backend for AMD GPUs. > - Experimental support for targeting macOS on 64-bit ARM. The > macOS package includes prebuilt druntime/Phobos libraries for > cross-compilation via `-mtriple=arm64-apple-macos`. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.24.0 > > Thanks to all contributors & sponsors! Thanks Martin! FYI: this is the first release that includes a working ThreadSanitizer. Curious to hear people's experiences with it. Cmdline flag: -fsanitize=thread https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual Examples: https://github.com/ldc-developers/ldc/blob/master/tests/sanitizers/tsan_tiny_race.d https://github.com/ldc-developers/ldc/blob/master/tests/sanitizers/tsan_tiny_race_TLS.d cheers, Johan From first.name at guess.com Sun Oct 25 13:59:44 2020 From: first.name at guess.com (Guillaume Piolat) Date: Sun, 25 Oct 2020 13:59:44 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Friday, 23 October 2020 at 18:01:19 UTC, Kagamin wrote: > On Tuesday, 20 October 2020 at 20:09:58 UTC, aberba wrote: >> Supposing I'm new to D, I have previous experience with >> LLVM-based compilers so I prefer to use LDC. How am I supposed >> to know what to do? Where is the information on how to get it >> on my system through visualD installer? >> >> The LDC experience needs some improvement here. > > Supposedly they will want an IDE with everything included in > one installer, like Visual Studio, and that's what VisualD > installer apparently does. How about this then? https://github.com/ldc-developers/ldc/pull/3598 From johan_forsberg_86 at hotmail.com Sun Oct 25 14:35:10 2020 From: johan_forsberg_86 at hotmail.com (Imperatorn) Date: Sun, 25 Oct 2020 14:35:10 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Sunday, 25 October 2020 at 13:59:44 UTC, Guillaume Piolat wrote: > On Friday, 23 October 2020 at 18:01:19 UTC, Kagamin wrote: >> On Tuesday, 20 October 2020 at 20:09:58 UTC, aberba wrote: >>> Supposing I'm new to D, I have previous experience with >>> LLVM-based compilers so I prefer to use LDC. How am I >>> supposed to know what to do? Where is the information on how >>> to get it on my system through visualD installer? >>> >>> The LDC experience needs some improvement here. >> >> Supposedly they will want an IDE with everything included in >> one installer, like Visual Studio, and that's what VisualD >> installer apparently does. > > How about this then? > > https://github.com/ldc-developers/ldc/pull/3598 ? From Patrick.Schluter at bbox.fr Mon Oct 26 07:14:55 2020 From: Patrick.Schluter at bbox.fr (Patrick Schluter) Date: Mon, 26 Oct 2020 07:14:55 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Saturday, 24 October 2020 at 00:00:02 UTC, starcanopy wrote: > On Friday, 23 October 2020 at 22:48:33 UTC, Imperatorn wrote: >> On Friday, 23 October 2020 at 20:21:39 UTC, aberba wrote: >>> On Friday, 23 October 2020 at 18:01:19 UTC, Kagamin wrote: >>>> [...] >>> >>> Not saying Kinke SHOULD do it. Was rather disagreeing with >>> the idea that "developers" don't use installers. And that's a >>> shortcoming with the LDC project...no straightforward way to >>> set it up on Windows using an installer. If visuald supports >>> LDC, why not point people to it. >>> >>> [...] >> >> I agree with this. Not providing an installer gives the >> message that you're not that interested in people using it. > > That's an exaggeration. Every release is accompanied by > binaries that one may easily retrieve. Setting up the > dependencies is only done once, and if you're a Windows > developer, such an environment most likely exists, and you'll > likely only have to add the bin to your path. It's my > understanding that there are few people regularly working on > LDC; allocating (voluntary!) manpower to a nice but > non-essential component doesn't seem wise. You underestimate how spoiled windows developer are. Even these simple step are completely out of character for most software on the platform. 20 years ago it wasn't a problem, now on Windows 10 it's a whole other story. How many clicks to get the dialog to set PATH? On NT4 it was 2 clicks, now on Windows 10 I still haven't figured out how to do it without searching like a madman. To make it short. The Windows platform is getting more and more hostile to manual tuning. From rikki at cattermole.co.nz Mon Oct 26 07:26:08 2020 From: rikki at cattermole.co.nz (rikki cattermole) Date: Mon, 26 Oct 2020 20:26:08 +1300 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On 26/10/2020 8:14 PM, Patrick Schluter wrote: > You underestimate how spoiled windows developer are. Even these simple > step are completely out of character for most software on the platform. > 20 years ago it wasn't a problem, now on Windows 10 it's a whole other > story. How many clicks to get the dialog to set PATH? On NT4 it was 2 > clicks, now on Windows 10 I still haven't figured out how to do it > without searching like a madman. > > To make it short. The Windows platform is getting more and more hostile > to manual tuning. Right click start menu, System -> System Info -> Advanced system settings -> Environment variables Or: Open start menu: type "environment", select "Edit environment variables for your account" Windows is hiding stuff that the majority of users should not need to know about. But everything is easily accessible if you know what you want to do (well everything except changing updates). From hostnet06 at gmail.com Mon Oct 26 09:02:16 2020 From: hostnet06 at gmail.com (Neha Sharma) Date: Mon, 26 Oct 2020 09:02:16 +0000 Subject: Dedicated server Message-ID: Hostnetindia is providing the best dedicated server for your website. In this, you can enjoy as you have the unique IP address, business email accounts, the Bandwidth limit is unlimited and you can have good disk space. There will be no problem with any RAM as it has more volume of RAM. A user cannot share it with others like shared hosting as you can access one website on it. Best Regards, https://hostnetindia.com/dedicated-server From assemblyislaw at gmail.com Mon Oct 26 15:28:56 2020 From: assemblyislaw at gmail.com (Streaksu) Date: Mon, 26 Oct 2020 15:28:56 +0000 Subject: webkit2gtkd 0.0.3 - WebKit2 bindings for GtkD Message-ID: I found myself recently for a project of mine in the need of bindings for the amazing Webkit2GTK library for D, using GtkD for ease of use, and now that they are working, sure someone can also find them useful! I made them using the gir-to-d tool by the GtkD team, and after that they just needed small tweaks here and there, if anyone wants to make bindings to libraries offering gobject-instrospection files, I truly recommend using the tool: https://github.com/gtkd-developers/gir-to-d I uploaded the bindings library to dub and github under the name webkit2gtkd: https://code.dlang.org/packages/webkit2gtkd https://github.com/streaksu/webkit2gtkd I hope other D + GtkD developers find it as useful as I have. I will be maintaining them as I use them myself, so if there are any issues please let me know! From spam at here.lot Mon Oct 26 19:37:19 2020 From: spam at here.lot (Kagamin) Date: Mon, 26 Oct 2020 19:37:19 +0000 Subject: LDC 1.24.0-beta1 In-Reply-To: References: Message-ID: On Monday, 26 October 2020 at 07:14:55 UTC, Patrick Schluter wrote: > You underestimate how spoiled windows developer are. Even these > simple step are completely out of character for most software > on the platform. 20 years ago it wasn't a problem, now on > Windows 10 it's a whole other story. How many clicks to get the > dialog to set PATH? On NT4 it was 2 clicks, now on Windows 10 I > still haven't figured out how to do it without searching like a > madman. > > To make it short. The Windows platform is getting more and more > hostile to manual tuning. I use set PATH=%SystemRoot%\system32;%SystemRoot% From karabutaworld at gmail.com Mon Oct 26 22:00:22 2020 From: karabutaworld at gmail.com (aberba) Date: Mon, 26 Oct 2020 22:00:22 +0000 Subject: webkit2gtkd 0.0.3 - WebKit2 bindings for GtkD In-Reply-To: References: Message-ID: On Monday, 26 October 2020 at 15:28:56 UTC, Streaksu wrote: > I found myself recently for a project of mine in the need of > bindings for the amazing Webkit2GTK library for D, using GtkD > for ease of use, and now that they are working, sure someone > can also find them useful! > > [...] Would be nice to see a sample usage in rhe read me. From geod24 at gmail.com Tue Oct 27 00:11:31 2020 From: geod24 at gmail.com (Mathias LANG) Date: Tue, 27 Oct 2020 00:11:31 +0000 Subject: LDC 1.24.0 In-Reply-To: References: Message-ID: On Saturday, 24 October 2020 at 15:11:08 UTC, kinke wrote: > Glad to announce LDC 1.24 - some highlights: > > - Based on D 2.094.1+. > - Support for LLVM 11. The prebuilt packages use v11.0.0, and > the x86 packages newly include the LLVM backend for AMD GPUs. > - Experimental support for targeting macOS on 64-bit ARM. The > macOS package includes prebuilt druntime/Phobos libraries for > cross-compilation via `-mtriple=arm64-apple-macos`. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.24.0 > > Thanks to all contributors & sponsors! Thanks for all your work on this and the great releases! From assemblyislaw at gmail.com Tue Oct 27 06:20:40 2020 From: assemblyislaw at gmail.com (Streaksu) Date: Tue, 27 Oct 2020 06:20:40 +0000 Subject: webkit2gtkd 0.0.3 - WebKit2 bindings for GtkD In-Reply-To: References: Message-ID: On Monday, 26 October 2020 at 22:00:22 UTC, aberba wrote: > On Monday, 26 October 2020 at 15:28:56 UTC, Streaksu wrote: >> I found myself recently for a project of mine in the need of >> bindings for the amazing Webkit2GTK library for D, using GtkD >> for ease of use, and now that they are working, sure someone >> can also find them useful! >> >> [...] > > Would be nice to see a sample usage in rhe read me. Thanks for the feedback! I added a simple helloworld example in the README, nothing fancy but should be enough to give people an example use so they can research the docs from there. From aldacron at gmail.com Tue Oct 27 10:59:25 2020 From: aldacron at gmail.com (Mike Parker) Date: Tue, 27 Oct 2020 10:59:25 +0000 Subject: DIP 1037--Add Unary Operator ...--Community Review Round 1 Begins Message-ID: The first round of Community Review for DIP 1037, "Add Unary Operator ...", is now under way. Please discuss the DIP (its merits, its implementation, peripheral topics, etc.) in the Discussion Thread and save all review feedback (critiques on the content of the DIP: what to change, how to improve it, etc.) for the Feedback Thread. Discussion Thread: https://forum.dlang.org/post/alsfzarhhszauufbxzqx at forum.dlang.org Feedback Thread: https://forum.dlang.org/post/rihufokcywwlityflfco at forum.dlang.org From nise at nise.com Tue Oct 27 12:16:00 2020 From: nise at nise.com (IGotD-) Date: Tue, 27 Oct 2020 12:16:00 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: > The DConf Online schedule is now live on the website. I've got > a blog post coming tomorrow which will, among other things, > include an announcement about the schedule aimed at the world > outside our community in a form suitable for /r/programming. > > https://dconf.org/2020/online/index.html Were the seminars recorded so that we can view them later? From aldacron at gmail.com Tue Oct 27 12:50:42 2020 From: aldacron at gmail.com (Mike Parker) Date: Tue, 27 Oct 2020 12:50:42 +0000 Subject: DConf Online 2020 Schedule In-Reply-To: References: Message-ID: On Tuesday, 27 October 2020 at 12:16:00 UTC, IGotD- wrote: > On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker > wrote: >> The DConf Online schedule is now live on the website. I've got >> a blog post coming tomorrow which will, among other things, >> include an announcement about the schedule aimed at the world >> outside our community in a form suitable for /r/programming. >> >> https://dconf.org/2020/online/index.html > > Were the seminars recorded so that we can view them later? The talks are prerecorded. But even the livestreams will still be available on our YouTube channel afterwards. From vit at vit.vit Tue Oct 27 16:26:10 2020 From: vit at vit.vit (vitamin) Date: Tue, 27 Oct 2020 16:26:10 +0000 Subject: sumtype 0.10.0: multiple dispatch In-Reply-To: References: Message-ID: On Thursday, 24 September 2020 at 02:28:11 UTC, Paul Backus wrote: > SumType is a generic sum type for modern D. It is designed to > be an improved > alternative to `std.variant.Algebraic`. > > Features: > - Pattern matching, including: > - Match-by-introspection ("if it compiles, it matches") (?) > - Multiple dispatch (?) > - Support for self-referential types (`This`). > - Works with `pure`, `@safe`, `@nogc`, `nothrow`, and > `immutable` (?) > - Compatible with `-betterC` and `-dip1000` (?) > - Zero runtime overhead compared to hand-written C > - No heap allocation > - Does not rely on runtime type information (`TypeInfo`) > (?) > > Starred features (?) are those that are missing from > `Algebraic`. > > The big new feature in this release is multiple dispatch: you > can pass multiple > SumType arguments to a single `match` call, and it will pass > each of those > SumTypes' values as a separate argument to the selected handler. > > If you're used to calling `match` with UFCS, the syntax for > passing multiple > arguments may take some getting used to. I recommend the > following idiom: > > bool sameDimensions(Point p1, Point p2) > { > // Set up your handlers first > alias doMatch = match!( > (Point2D _1, Point2D _2) => true, > (Point3D _1, Point3D _2) => true, > (_1, _2) => false > ); > > // Now make the actual call > return doMatch(p1, p2); > } > > Other improvements since 0.9.0, the last announced version: > - SumTypes can be used as keys in associative arrays > - isSumType!T is now true if T implicitly converts to a > SumType > - sumtype's license has been changed from MIT to Boost 1.0 > - Member types with non-const `opEquals` overloads finally > work correctly > - Various other bug fixes and documentation improvements > > Links: > - Documentation: > https://pbackus.github.io/sumtype/sumtype.html > - DUB: https://sumtype.dub.pm > - Github: https://github.com/pbackus/sumtype Hello, Older version of sumtype accept this code: void main(){ import sumtype; alias Val = SumType!(bool); const bool b = true; Val val = b; //fail in newest version val = b; //fail in newest version } but new version need exact type: void main(){ import sumtype; alias Val = SumType!(bool); bool b = true; //cannot be const Val val = b; val = b; } is it bug in new version or old version? From snarwin at gmail.com Tue Oct 27 16:42:25 2020 From: snarwin at gmail.com (Paul Backus) Date: Tue, 27 Oct 2020 16:42:25 +0000 Subject: sumtype 0.10.0: multiple dispatch In-Reply-To: References: Message-ID: On Tuesday, 27 October 2020 at 16:26:10 UTC, vitamin wrote: > > Hello, > > Older version of sumtype accept this code: > > void main(){ > import sumtype; > alias Val = SumType!(bool); > > const bool b = true; > Val val = b; //fail in newest version > val = b; //fail in newest version > } > > but new version need exact type: > > > void main(){ > import sumtype; > alias Val = SumType!(bool); > > bool b = true; //cannot be const > Val val = b; > val = b; > } > > is it bug in new version or old version? It's a bug in the new version. Thanks for reporting. I've opened an issue on Github for this: https://github.com/pbackus/sumtype/issues/47 From qs.il.paperinik at gmail.com Wed Oct 28 02:22:14 2020 From: qs.il.paperinik at gmail.com (Q. Schroll) Date: Wed, 28 Oct 2020 02:22:14 +0000 Subject: DIP 1030-- Named Arguments--Formal Assessment In-Reply-To: References: Message-ID: On Thursday, 8 October 2020 at 14:05:14 UTC, Andre Pany wrote: > how to this new feature interact with opDispatch? Will there be > any possibility to extract the argument names in opDispatch? Good catch. The DIP doesn't mention opDispatch and it's probably too late to change. I also don't really see a non-breaking way to tell opDispatch about parameter names. Giving opDispatch a string[] of named arguments' names (with "" for a name-less argument) would probably do the job, but it's a breaking change. A different solution would be a new operator method called `opDispatchNamed` or alike that does exactly that. However, opDispatch is designed to be used when `c` in expr.c cannot be resolved, where expr.c(args) is a special case where `c` happens to be "something callable". I'd say, the problem should be solved on a more general level: function templates *in general* (opDispatch included) should have a way to get named arguments' names. One possibility would be a magic __ARG_NAMES__ that returns a compile-time string[] that contains that names, like __FILE__ and __LINE__ at call site if used as a default parameter. So you'd use it like: auto opDispatch( string methodName, string[] argNames = __ARG_NAMES__, T, Ts... )(T arg, Ts args) { // argNames[0] will be "arg" always since it's not an pack. } That way, it could be non-breaking and more useful. From andre at s-e-a-p.de Wed Oct 28 16:09:57 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Wed, 28 Oct 2020 16:09:57 +0000 Subject: DIP 1030-- Named Arguments--Formal Assessment In-Reply-To: References: Message-ID: On Wednesday, 28 October 2020 at 02:22:14 UTC, Q. Schroll wrote: > On Thursday, 8 October 2020 at 14:05:14 UTC, Andre Pany wrote: >> [...] > > Good catch. The DIP doesn't mention opDispatch and it's > probably too late to change. I also don't really see a > non-breaking way to tell opDispatch about parameter names. > Giving opDispatch a string[] of named arguments' names (with "" > for a name-less argument) would probably do the job, but it's a > breaking change. > > [...] Thank you a lot for your analysis. Once the feature is implemented I will create a feature request and add your proposal. Kind regards Andre From igor.khasilev at gmail.com Thu Oct 29 06:42:54 2020 From: igor.khasilev at gmail.com (ikod) Date: Thu, 29 Oct 2020 06:42:54 +0000 Subject: requests 2.0.0 release Message-ID: Hi, requests 2.0.0 released with single change - support for vibe-d moved to separate subpackage. The goal of this update is to prevent dub from downloading vibe-d packages for optional subConfiguration. Important in case you use requests with vibe-d: starting from this release instead of using subConfiguration for requests in your dub.json you have to use package requests:vibed in dependencies. dlang-requests is http/ftp client library inspired by python requests https://github.com/ikod/dlang-requests best regards, Igor From andre at s-e-a-p.de Thu Oct 29 11:15:51 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Thu, 29 Oct 2020 11:15:51 +0000 Subject: requests 2.0.0 release In-Reply-To: References: Message-ID: On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: > Hi, > > requests 2.0.0 released with single change - support for vibe-d > moved to separate subpackage. > > The goal of this update is to prevent dub from downloading > vibe-d packages for optional subConfiguration. > > Important in case you use requests with vibe-d: starting from > this release instead of using subConfiguration for requests in > your dub.json you have to use package requests:vibed in > dependencies. > > > dlang-requests is http/ftp client library inspired by python > requests > https://github.com/ikod/dlang-requests > > best regards, > Igor This is fantastic work, thanks a lot. It could also serve as template for other projects how to integrate with vibe-d without actually depending on it. Kind regards Andre From alireza6677 at gmail.com Thu Oct 29 16:00:33 2020 From: alireza6677 at gmail.com (Alireza SN) Date: Thu, 29 Oct 2020 16:00:33 +0000 Subject: requests 2.0.0 release In-Reply-To: References: Message-ID: On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: > Hi, > > requests 2.0.0 released with single change - support for vibe-d > moved to separate subpackage. > > ... > > best regards, > Igor This is great! Thank you. From zorael at gmail.com Thu Oct 29 16:22:50 2020 From: zorael at gmail.com (Anonymouse) Date: Thu, 29 Oct 2020 16:22:50 +0000 Subject: requests 2.0.0 release In-Reply-To: References: Message-ID: On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: > Hi, > > requests 2.0.0 released with single change - support for vibe-d > moved to separate subpackage. Thanks for all your hard work! This was an annoying point and I'm happy to see a solution that works for everyone. From igor.khasilev at gmail.com Thu Oct 29 18:17:38 2020 From: igor.khasilev at gmail.com (ikod) Date: Thu, 29 Oct 2020 18:17:38 +0000 Subject: requests 2.0.0 release In-Reply-To: References: Message-ID: On Thursday, 29 October 2020 at 16:22:50 UTC, Anonymouse wrote: > On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: >> Hi, >> >> requests 2.0.0 released with single change - support for >> vibe-d moved to separate subpackage. > > Thanks for all your hard work! This was an annoying point and > I'm happy to see a solution that works for everyone. Thanks everybody for your motivating words! I hope that next update will include native Windows SSL, I made some progress in this direction. Regards, Igor From spam at here.lot Fri Oct 30 10:12:58 2020 From: spam at here.lot (Kagamin) Date: Fri, 30 Oct 2020 10:12:58 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Tuesday, 13 October 2020 at 10:30:41 UTC, jmh530 wrote: > The difference is that MIT says you can use it without > restriction, including a few things, while Boost says you can > do some things. I only meant that MIT license was more > permissive in that if there are other things you want to do > with it that are not listed on Boost (I don't know what that > would be), then MIT would allow it. Just make sure you don't grant exclusive rights :) From john.michael.hall at gmail.com Fri Oct 30 12:24:06 2020 From: john.michael.hall at gmail.com (jmh530) Date: Fri, 30 Oct 2020 12:24:06 +0000 Subject: mir-stat In-Reply-To: References: Message-ID: On Friday, 30 October 2020 at 10:12:58 UTC, Kagamin wrote: > On Tuesday, 13 October 2020 at 10:30:41 UTC, jmh530 wrote: >> The difference is that MIT says you can use it without >> restriction, including a few things, while Boost says you can >> do some things. I only meant that MIT license was more >> permissive in that if there are other things you want to do >> with it that are not listed on Boost (I don't know what that >> would be), then MIT would allow it. > > Just make sure you don't grant exclusive rights :) Ilya ended up going with the Apache license. https://github.com/libmir/mir-algorithm/blob/master/LICENSE From doob at me.com Fri Oct 30 13:34:24 2020 From: doob at me.com (Jacob Carlborg) Date: Fri, 30 Oct 2020 13:34:24 +0000 Subject: requests 2.0.0 release In-Reply-To: References: Message-ID: On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: > Hi, > > requests 2.0.0 released with single change - support for vibe-d > moved to separate subpackage. > > The goal of this update is to prevent dub from downloading > vibe-d packages for optional subConfiguration. Another approach is to check if vibe.d is available using version conditions [1]. This is how the DDB [2] package supports both vibe.d sockets and Phobos sockets. [1] https://github.com/pszturmaj/ddb/blob/97bc3652b05492e7917888c92e59f4576a69dfa8/source/ddb/postgres.d#L189-L216 [2] https://code.dlang.org/packages/ddb -- /Jacob Carlborg From andre at s-e-a-p.de Fri Oct 30 13:40:24 2020 From: andre at s-e-a-p.de (Andre Pany) Date: Fri, 30 Oct 2020 13:40:24 +0000 Subject: requests 2.0.0 release In-Reply-To: References: Message-ID: On Friday, 30 October 2020 at 13:34:24 UTC, Jacob Carlborg wrote: > On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote: >> Hi, >> >> requests 2.0.0 released with single change - support for >> vibe-d moved to separate subpackage. >> >> The goal of this update is to prevent dub from downloading >> vibe-d packages for optional subConfiguration. > > Another approach is to check if vibe.d is available using > version conditions [1]. This is how the DDB [2] package > supports both vibe.d sockets and Phobos sockets. > > [1] > https://github.com/pszturmaj/ddb/blob/97bc3652b05492e7917888c92e59f4576a69dfa8/source/ddb/postgres.d#L189-L216 > [2] https://code.dlang.org/packages/ddb > > -- > /Jacob Carlborg The important point here is, fetching and building "requests" does no longer trigger downloads of vibe.d packages. This is the case for ddb(?). Therefore I see the pattern "requests" is using, is also highly interesting for ddb. Kind regards Andre From johan_forsberg_86 at hotmail.com Sat Oct 31 12:32:53 2020 From: johan_forsberg_86 at hotmail.com (Imperatorn) Date: Sat, 31 Oct 2020 12:32:53 +0000 Subject: LDC 1.24.0 In-Reply-To: References: Message-ID: On Saturday, 24 October 2020 at 15:11:08 UTC, kinke wrote: > Glad to announce LDC 1.24 - some highlights: > > - Based on D 2.094.1+. > - Support for LLVM 11. The prebuilt packages use v11.0.0, and > the x86 packages newly include the LLVM backend for AMD GPUs. > - Experimental support for targeting macOS on 64-bit ARM. The > macOS package includes prebuilt druntime/Phobos libraries for > cross-compilation via `-mtriple=arm64-apple-macos`. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.24.0 > > Thanks to all contributors & sponsors! Splendid!