Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 04:51:23 UTC, Manu wrote: Out of curiosity... what's going on with mine? Is there something I'm meant to have done? It's kinda just hanging out no? Yours is in the Post-Community review stage [1]: "A DIP may remain in the Post-Community Round N status for a maximum of 180 days. Periodically, the DIP Manager will determine if any post-community DIP is ready to move forward to the Final Review stage. Only one DIP may be in this stage at any given time." 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 recently sent 1014 to Walter and Andrei for Formal Assessment, with 1013 waiting to go when it's done. I don't know when I'll receive their decision, so I'm slowing the pace down for now. I see the Post-Community round as a staging area for the end game and would very much prefer to have as little time as possible for each DIP in the Post-Final stage. That way the Final Review feedback doesn't get too stale before it goes to Walter & Andrei. I intend to move 1015 into Final Review within the next couple of weeks if the author is ready, so it will be at least a month before yours moves forward. That ultimately depends on how soon Walter & Andrei give me a decision on 1014. [1] https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review [2] https://github.com/dlang/DIPs/blob/master/DIPs/README.md
Re: DIP Draft Reviews
On Wed, 5 Sep 2018 at 20:30, Mike Parker via Digitalmars-d-announce wrote: > > On Wednesday, 5 September 2018 at 14:30:14 UTC, rikki cattermole > wrote: > > > > > Last time I checked, it should be me and yshui's named > > parameter DIP's next, they really need to be reviewed together > > though, at least initially. > > I'm not at all thrilled by the idea of running two DIPs through > the queue in concert and would prefer to avoid that circumstance. > > I've already discussed this with Yuxuan and asked if he'd be > willing work together with you on a single DIP. His response was > that the two proposals are not mutually exclusive and that yours > could be built on top of his. > > I need to take the time to fully absorb both DIPs and then I'll > decide how to approach it. But you'll be hearing from me as soon > as I do. Out of curiosity... what's going on with mine? Is there something I'm meant to have done? It's kinda just hanging out no?
Re: DIP Draft Reviews
On Wednesday, 5 September 2018 at 14:30:14 UTC, rikki cattermole wrote: Last time I checked, it should be me and yshui's named parameter DIP's next, they really need to be reviewed together though, at least initially. I'm not at all thrilled by the idea of running two DIPs through the queue in concert and would prefer to avoid that circumstance. I've already discussed this with Yuxuan and asked if he'd be willing work together with you on a single DIP. His response was that the two proposals are not mutually exclusive and that yours could be built on top of his. I need to take the time to fully absorb both DIPs and then I'll decide how to approach it. But you'll be hearing from me as soon as I do.
Re: DIP Draft Reviews
On Wednesday, 5 September 2018 at 14:20:38 UTC, Nicholas Wilson wrote: pull/101 was closed. What's happening now? 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
Re: D kernel for Jupyter notebook
On Tuesday, 4 September 2018 at 04:58:41 UTC, Shigeki Karita wrote: On Monday, 20 August 2018 at 00:14:03 UTC, Shigeki Karita wrote: On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: Proof of concept works, but it requires some further development to be useful to do work in. [...] Great. I have tried DUB integration. It seems to work. https://github.com/ShigekiKarita/grain/blob/master/example/repl.d I'm making a jupyter based tutorial for my library. It might be the first example for jupyterd. https://github.com/ShigekiKarita/grain/blob/master/tutorial.ipynb Very cool. Thank you. I was looking into Jupyter widgets. I ported over some of it and had to add the extension to protocol for widgets into the notebook. It's not that bad and might be pretty useful to be able to access widgets from D. Half-finished code right now that doesn't even build but I don't have so much time and won't for a couple of months.
Re: expectations 0.1.0
On Tuesday, 4 September 2018 at 22:08:48 UTC, Nick Sabalausky (Abscissa) wrote: I think you may be getting hung up on a certain particular detail of Vladimir's exact "draft" implementation of Success, whereas I'm focusing more on Success's more general point of "Once the object is no longer around, guarantee the error doesn't get implicitly squelched." You're right that, *in the draft implementation as-is*, it can be awkward for the caller to then pass the Success along to some other code (another function call, or something higher up the stack). *Although*, still not impossible. So #3 still isn't eliminated, it's simply made awkward... But reference counting would be enough to fix that. (Or a compiler-supported custom datatype that's automatically pass-by-moving, but that's of course not something D has). Ok, I think I understand what you're proposing now--basically, something comparable to Rust's `#[must_use]` attribute. Thanks for taking the time to explain. I agree that that would be a nice feature for `Expected` to have. The thing is, D already has a mechanism for signalling failures that can't be ignored: exceptions. So adding that functionality to `Expected`, while convenient, doesn't actually let you accomplish anything you couldn't already. Now, if it were easy to implement, then sure, no problem. But it's not. Reference counting in particular is so problematic that Walter and Andrei have proposed *multiple* new language features (copy constructors, __mutable) to make it work cleanly. As things currently stand, making `Expected` reference-counted would mean at the very least giving up compatibility with `const` and `immutable`, which makes `Expected` a worse fit for strongly-pure functions (currently its *best* use-case). It's a shame that D forces us to make this tradeoff, but given the options in front of me, I would rather have `Expected` shine in the area where it has a comparative advantage, even if that means making it less universally-applicable as an error-handling mechanism.
Re: DIP Draft Reviews
On 06/09/2018 2:20 AM, Nicholas Wilson wrote: On Monday, 20 August 2018 at 14:54:24 UTC, Mike Parker wrote: I'm getting ready to start prepping one of the DIPs in the PR queue for community review. It proposes adding an `in` operator for arrays. I haven't gone through it in detail yet, so I invite anyone with time on their hands to provide feedback on the Draft so we can more speedily get in shape to kick off the big-league reviews. https://github.com/dlang/DIPs/pull/101 While you're at it, feel free to poke around and leave some feedback on other drafts in the queue. pull/101 was closed. What's happening now? Last time I checked, it should be me and yshui's named parameter DIP's next, they really need to be reviewed together though, at least initially.
Re: DIP Draft Reviews
On Monday, 20 August 2018 at 14:54:24 UTC, Mike Parker wrote: I'm getting ready to start prepping one of the DIPs in the PR queue for community review. It proposes adding an `in` operator for arrays. I haven't gone through it in detail yet, so I invite anyone with time on their hands to provide feedback on the Draft so we can more speedily get in shape to kick off the big-league reviews. https://github.com/dlang/DIPs/pull/101 While you're at it, feel free to poke around and leave some feedback on other drafts in the queue. pull/101 was closed. What's happening now?
