Re: LDC 1.12.0-beta1
On Wednesday, 5 September 2018 at 05:15:45 UTC, Joakim wrote: I'll add native beta builds for Android in a couple days. The native Android builds are up at the above github release link. I think this is the last time I'll put beta builds out, too much of a PITA to rebuild llvm each time. I'll continue maintaining the ldc package in the official Termux package repo though. The Termux package build script used to build these betas is online here: https://github.com/joakim-noah/termux-packages/tree/beta/packages/ldc-beta
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 17:44:28 UTC, Jonathan M Davis wrote: Of course, what further complicates things here is that the author is Walter, and ultimately, it's Walter and Andrei who make the decision on their own. And if Walter doesn't respond to any of the feedback or address it in the DIP, it all comes across as if the DIP itself is just a formality. The fact that he wrote a DIP and presented it for feedback is definitely better than him simply implementing it, since it does give him the chance to get feedback on the plan and improve upon it, but if he then doesn't change anything or even respond to any of the review comments, then it makes it seem kind of pointless that he bothered with a DIP. At that point, it just serves as documentation of his intentions. This is all in stark contrast to the case where someone other than Walter or Andrei wrote the DIP, and the author doesn't bother to even respond to the feedback let alone incorporate it, since they then at least still have to get the DIP past Walter and Andrei, and if the DIP has not taken any of the feedback into account, then presumably, it stands a much worse chance of making it through. On the other hand, if the DIP comes from Walter or Andrei, they only have the other person to convince, and that makes it at least seem like there's a decent chance that it's just going to be rubber-stamped when the DIP author doesn't even respond to feedback. I think that it's great for Walter and Andrei to need to put big changes through the DIP process just like the rest of us do, but given that they're the only ones deciding what's accepted, it makes the whole thing rather weird when a DIP comes from them. - Jonathan M Davis If Walter had tried to implement this w/o a DIP, that would have been among the first reviews received, so it is good that he's has done it as a DIP. But not using it for improving the design is almost as bad. I view this DIP like DIP1000 but worse: at least with DIP1000 there was clear motivation, and despite any breakage and poor documentation of continued changes due to unforeseen requirements, it solves a real problem and has bought real value. It could have been handled much better, but is a net positive IMO. DIP1017 OTOH has flawed/unsubstantiated motivation, will break lots of code, and solves a problem that is already solved by GDC/LDC where the only benefit other that documentation is faster code and could be solved in the same way as GDC/LDC with none of the breakage and complications. Any marginal benefits in speed of compiled code for DMD _only_ (which is not why one uses DMD) comes at the cost of: opportunity cost of development/review and ongoing implementation fixes; unknown but probably very large code breakages; slower compile times for all three compilers; increased complexity in the type system and for new users; and all the other reasons listed in the draft and community review. IMO, a very much net negative I now understand why Mihails left over DIP1000...
Re: DIP Draft Reviews
On Thursday, September 6, 2018 4:49:55 AM MDT Mike Parker via Digitalmars-d- announce wrote: > On Thursday, 6 September 2018 at 10:22:47 UTC, Nicholas Wilson > > wrote: > > Put it this way: DIP1017 should not go to formal without > > change, as it did from draft to community (which I don't think > > should have happened without at least some acknowledgement or > > refutation of the points raised in draft). > > I always ask DIP authors about unaddressed feedback before moving > from one stage to the other, and I did so with DIP 1017 when > moving out of Draft Review. It's entirely up to the author > whether or not to address it and there is no requirement for DIP > authors to respond to any feedback. I would prefer it if they > did, especially in the Post-Community stage and later as it helps > me with my review summaries, but 1017 is not the first DIP where > feedback went unaddressed and I'm sure it won't be the last. Of course, what further complicates things here is that the author is Walter, and ultimately, it's Walter and Andrei who make the decision on their own. And if Walter doesn't respond to any of the feedback or address it in the DIP, it all comes across as if the DIP itself is just a formality. The fact that he wrote a DIP and presented it for feedback is definitely better than him simply implementing it, since it does give him the chance to get feedback on the plan and improve upon it, but if he then doesn't change anything or even respond to any of the review comments, then it makes it seem kind of pointless that he bothered with a DIP. At that point, it just serves as documentation of his intentions. This is all in stark contrast to the case where someone other than Walter or Andrei wrote the DIP, and the author doesn't bother to even respond to the feedback let alone incorporate it, since they then at least still have to get the DIP past Walter and Andrei, and if the DIP has not taken any of the feedback into account, then presumably, it stands a much worse chance of making it through. On the other hand, if the DIP comes from Walter or Andrei, they only have the other person to convince, and that makes it at least seem like there's a decent chance that it's just going to be rubber-stamped when the DIP author doesn't even respond to feedback. I think that it's great for Walter and Andrei to need to put big changes through the DIP process just like the rest of us do, but given that they're the only ones deciding what's accepted, it makes the whole thing rather weird when a DIP comes from them. - Jonathan M Davis
Re: Dub support was added to Meson
On Thu, 2018-08-16 at 22:44 +, Filipe Laíns via Digitalmars-d-announce wrote: […] Apologies for the delay in replying to this one. > This is obviously bad. Your distro has a package manager, you > should use it, not create a separated language-specific one. If I'm afraid you are onto a lost cause on this one. The whole JVM-based milieu, Ruby, Python, Go, D, Rust, etc. all have language specific repositories. Debian, Fedora, etc. pick and choose which bits they choose to package based on some algorithm almost, but not quite, totally unrelated to what is the latest version. Operating system package managers are providing the operating system, not the development tools and dependencies needed for software development. Go, Rust, and indeed D, are going the route of static compilation as much because operating system dependencies can never be guaranteed, and are often wrong. It is not clear to me why Debian spend so much time packaging bits of the Go universe that no-one uses even if the dependencies are in fact used. On the other hand, having GtkD (and GStreamerD) packaged is great since there are shared objects for use with D codes. There is nothing quite so depressing as waiting for LDC or DMD to statically link to GtkD. So static linking is not something I want. But waiting for Debian and Fedora to package things is often like Waiting for Godot. Hence "build it yourself" becomes a bit of a must. This is not a simple situation, and every individuals positions on it is likely inconsistent and full of holes. > you are doing this locally, either but using the user's home of > by installing to /usr/local, I don't think it's much of a > problem. If you are implementing something like this at least do > it in a way that the package managing feature is optional. I > don't know if I'm being biased by being an Archlinux TU but from > my perspective, it's not something we should do, at the very > least globally. It may be that Arch stays more up to date than Debian and Fedora (because it is less centralised and more like Homebrew/Linuxbrew, but Debian (and Fedora?) is where the bulk of Linux programs get executed, and so is the obvious place to develop. > Weirdly enough, I can reproduce. This was working when I wrote > the patch. I've opened an issue in the upstream. Excellent. I have a clone of Meson so can try stuff out on master/HEAD as needed. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 11:18:25 UTC, Nicholas Wilson wrote: I can understand not requiring authors to respond to all the feedback, but not requiring them to respond to _any_ is just wasting everyone's time, since _all_ of the previous points will be bought up again and the next stage will be a repeat of the previous. Yeah, I agree that if nothing or almost nothing is addressed (even by explaining why the raised issues didn't convince) that should prevent the DIP from moving forward.
Re: LDC 1.12.0-beta1
On Tuesday, 4 September 2018 at 22:47:39 UTC, kinke wrote: * LTO working for Win64 targets. Wow! Thank you.
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 10:49:55 UTC, Mike Parker wrote: I always ask DIP authors about unaddressed feedback before moving from one stage to the other, and I did so with DIP 1017 when moving out of Draft Review. It's entirely up to the author whether or not to address it and there is no requirement for DIP authors to respond to any feedback. I would prefer it if they did, especially in the Post-Community stage and later as it helps me with my review summaries, but 1017 is not the first DIP where feedback went unaddressed and I'm sure it won't be the last. I can understand not requiring authors to respond to all the feedback, but not requiring them to respond to _any_ is just wasting everyone's time, since _all_ of the previous points will be bought up again and the next stage will be a repeat of the previous.
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 10:22:47 UTC, Nicholas Wilson wrote: Put it this way: DIP1017 should not go to formal without change, as it did from draft to community (which I don't think should have happened without at least some acknowledgement or refutation of the points raised in draft). I always ask DIP authors about unaddressed feedback before moving from one stage to the other, and I did so with DIP 1017 when moving out of Draft Review. It's entirely up to the author whether or not to address it and there is no requirement for DIP authors to respond to any feedback. I would prefer it if they did, especially in the Post-Community stage and later as it helps me with my review summaries, but 1017 is not the first DIP where feedback went unaddressed and I'm sure it won't be the last.
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 09:41:39 UTC, Dukc wrote: I disagree. Reviews are mainly for giving feedback, not for deciding the fate of the DIP -that's what the formal assesment is for. For the draft review yes, but the points against the DIP were raised in draft and it proceeded to community review unchanged without any correspondence on the part of the author, except to state that a reason to extend the DIP to extern(C++) function wouldn't work. IMO, it's enough that the author reads the review and addresses the points in the DIP before the next phase. I agree, but see previous point. And not every point has to be blindly addressed, No, but I expect a fraction greater then zero to be addressed. the reviewers may be just as wrong as the author. Yes but the reviewers outnumber the author by a lot, and in aggregate are less likely to be. That's why there are multiple reviewers. The reviews are still mentioned in the DIPs so they can be considered in the formal assesment, addressed by the author or not. And of course it's always better if the author interactively participates at the review, but it should not be required IMO. Put it this way: DIP1017 should not go to formal without change, as it did from draft to community (which I don't think should have happened without at least some acknowledgement or refutation of the points raised in draft).
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 07:13:20 UTC, Nicholas Wilson wrote: IMO the DIP author should at least participate in the community review if they expect their DIP to have _any_ chance of success. I disagree. Reviews are mainly for giving feedback, not for deciding the fate of the DIP -that's what the formal assesment is for. IMO, it's enough that the author reads the review and addresses the points in the DIP before the next phase. And not every point has to be blindly addressed, the reviewers may be just as wrong as the author. The reviews are still mentioned in the DIPs so they can be considered in the formal assesment, addressed by the author or not. And of course it's always better if the author interactively participates at the review, but it should not be required IMO.
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 05:25:11 UTC, Mike Parker wrote: I've got three DIPs in the Post-Community stage right now [2]. DIP 1015 will move to Final Review before yours if its author is ready when I am, then yours will go before 1017. I'm a bit worried about 1017 going in to final, given the large, unresolved criticisms in both draft and community review rounds. IMO the DIP author should at least participate in the community review if they expect their DIP to have _any_ chance of success.
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 03:19:33 UTC, Mike Parker wrote: I'm not going to start another Community Review until I get some space in the latter end of the queue. But soon I'll be asking for Draft Review feedback on the next candidate. Right now that's likely to be 'Named arguments lite', but it be Rikki's. https://github.com/dlang/DIPs/pull/123 Did you a word? Anyway good to know that things are still moving forward.
