Re: Release fluent-asserts 0.6.0
On Sunday, 2 July 2017 at 13:34:25 UTC, Szabo Bogdan wrote: Any feedback is appreciated. Thanks, Bogdan Hi, if you're just looking for other ideas, you might want to look at adding capabilities like in the java hamcrest matchers. You might also want to support regular expression matches in the string matchers. http://hamcrest.org/JavaHamcrest/javadoc/1.3/org/hamcrest/Matchers.html These were used in swtbot, which made a very nice testing environment for their swt gui widgets. Swtbot added filtering for the context of the match as well. You can get a feel for it in this article. There is a DWT library translated from java swt, but this testing app wasn't ported. http://www.vogella.com/tutorials/SWTBot/article.html
DIP 1007--"future symbol"--Has Been Accepted
Congratulations to Mihails Strasuns, a.k.a. Dicebot, on the acceptance of his DIP 1007, '"future symbol" Compiler Concept'! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md Although the proposal recommended that the feature be implemented only internally for DRuntime initially, Walter felt that isn't necessary. So once implemented, the feature will be available for immediate use. Thanks are due to Sociomantic, particularly Leandro Lucarella, who answered Walter's questions on Sociomantic's usage of the feature in their code base. In other DIP news, I'm tentatively planning to merge DIP 1011 and begin its preliminary review in the coming week. This is going to be the "extern(delegate)" proposal from Jonathan Marler. I invite everyone to participate in the draft review on the PR over the next few days. https://github.com/dlang/DIPs/pull/74 Another DIP in the queue in need of a draft review is Nicholas Wilson's proposal to allow changing the default attributes (like @system vs. @safe, @nogc vs. 'uses GC'). This DIP follows on from a recent discussion here in the forums. The sooner we can get feedback on the PR, the sooner I'll be ready to merge it and begin the review process. https://github.com/dlang/DIPs/pull/75 Finally, I find that DIP 1010, Timon Gehr's "static foreach", received no external input in the draft review, and no feedback during the preliminary review -- the discussion thread is empty! Either it was completely ignored or it's so well put together that it warrants no criticism. I'm inclined to believe that it's the latter. With that in mind, I'm going to push it on to the formal review without the normal two-week window for feedback. I'll make the announcement on Monday, then if there is no feedback by Wednesday that warrants keeping it open, I'll submit it to Walter and Andrei for judgement. So please read the DIP if you haven't already and consider over the weekend if you have anything to say about it. If so, then you can post it in the thread I'll open on Monday. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md
Re: Go Your Own Way (Part One: The Stack)
On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote: On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under: version (DigitalMars) I read this as CRuntime_DigitalMars, which prompted a search that led me to a page at MSDN on _alloca, which gave me a compiler error when I prototyped it, which led to my prototyping alloca for CRuntime_Microsoft and finding success, which has now confirmed my worry that publishing without a review was a bad idea. I've updated the post. Thanks!
Re: Release candidates vibe.d 0.8.0-rc.6 and vibe-core 1.0.0-rc.4
There have been two more regression fixes: - (De)serialization of self-referential types was broken (@safe related compile error) - The .parentPath property of the new path types in vibe-core was broken The release date is still scheduled for Monday.
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under: version (DigitalMars)
Re: Go Your Own Way (Part One: The Stack)
On Fri, Jul 07, 2017 at 07:12:28PM -0600, Jonathan M Davis via Digitalmars-d-announce wrote: > On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d- > announce wrote: [...] > > The implicit slice is one of what I see as D's design flaws and > > brings up a number of problems. dip1000 and similar things might be > > able to fix the problems without changing the feature, but I won't > > be surprised if after a couple more years, we see that implicit > > slice get deprecated. I'm also against implicit slicing of static arrays. It's just too dangerous, and also interacts poorly with template functions. > The trick is convincing Walter. The last time I brought it up with > him, he thought that improvements to @safe would fix the problem - and > they will help - but it interacts badly with templated code, and I > think that from a code clarity standpoint, the slicing needs to be > explicit. So, I'm of the opinion that implicit slicing should simply > be deprecated regardless of the state of @safe, but I don't know how > possible it is to convince Walter of that. Fixing the @safe issues is > at least a start though. [...] It's true that fixing @safe issues will at least reduce the problem surface of implicit slicing. But it's like bandaid over a festering wound; the problem is still there, it just lurks in more obscure corners now. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Re: Go Your Own Way (Part One: The Stack)
On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d- announce wrote: > I would add a note to the "static arrays are interchangeable with > dynamic arrays" saying that you can... and probably should > explicitly slice them with `[]`. > > The implicit slice is one of what I see as D's design flaws and > brings up a number of problems. dip1000 and similar things might > be able to fix the problems without changing the feature, but I > won't be surprised if after a couple more years, we see that > implicit slice get deprecated. The trick is convincing Walter. The last time I brought it up with him, he thought that improvements to @safe would fix the problem - and they will help - but it interacts badly with templated code, and I think that from a code clarity standpoint, the slicing needs to be explicit. So, I'm of the opinion that implicit slicing should simply be deprecated regardless of the state of @safe, but I don't know how possible it is to convince Walter of that. Fixing the @safe issues is at least a start though. - Jonathan M Davis
Re: Go Your Own Way (Part One: The Stack)
On Friday, 7 July 2017 at 22:42:08 UTC, Walter Bright wrote: On 7/7/2017 1:33 PM, Steven Schveighoffer wrote: Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements about it). DMD will. I don't know about LDC or GDC. It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead.
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 1:33 PM, Steven Schveighoffer wrote: Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements about it). DMD will. I don't know about LDC or GDC.
Re: Go Your Own Way (Part One: The Stack)
On 7/7/17 4:10 PM, Walter Bright wrote: On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements about it). -Steve
Re: Go Your Own Way (Part One: The Stack)
On 07-07-17 22:10, Walter Bright wrote: On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib Only for version DigitalMars and GNU. -- Mike Wey
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 12:36 PM, Steven Schveighoffer wrote: I thought alloca was an intrinsic? Which means that the compiler generates inline code to add to the stack. I would think it has to do this, since actually calling a function would generate a new stack frame. Yes and yes.
Re: Go Your Own Way (Part One: The Stack)
On 7/7/17 3:36 PM, Steven Schveighoffer wrote: I thought alloca was an intrinsic? Which means that the compiler generates inline code to add to the stack. Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). -Steve
Re: Go Your Own Way (Part One: The Stack)
On 7/7/17 8:59 AM, Mike Parker wrote: This is my latest post in the GC series. I had promised the next one would look at non-GC allocation strategies, but as it got longer and longer I decided to break it up into two parts. This part covers stack allocations. The next one will deal with non-GC heap allocations. If my luck holds out, we're about to see a flurry of guest posts and collaborations over the next few weeks. If that pans out, I expect to publish the part two in mid-late August. The blog: https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/ Reddit: https://www.reddit.com/r/programming/comments/6ltfwx/go_your_own_way_part_one_of_two_on_nongc/ I thought alloca was an intrinsic? Which means that the compiler generates inline code to add to the stack. I would think it has to do this, since actually calling a function would generate a new stack frame. -Steve
Re: Go Your Own Way (Part One: The Stack)
On Friday, 7 July 2017 at 13:48:47 UTC, Adam D. Ruppe wrote: I would add a note to the "static arrays are interchangeable with dynamic arrays" saying that you can... and probably should explicitly slice them with `[]`. The implicit slice is one of what I see as D's design flaws and brings up a number of problems. dip1000 and similar things might be able to fix the problems without changing the feature, but I won't be surprised if after a couple more years, we see that implicit slice get deprecated. +1 it only creates confusion
Re: Go Your Own Way (Part One: The Stack)
I would add a note to the "static arrays are interchangeable with dynamic arrays" saying that you can... and probably should explicitly slice them with `[]`. The implicit slice is one of what I see as D's design flaws and brings up a number of problems. dip1000 and similar things might be able to fix the problems without changing the feature, but I won't be surprised if after a couple more years, we see that implicit slice get deprecated.
Re: Go Your Own Way (Part One: The Stack)
On Friday, 7 July 2017 at 12:59:44 UTC, Mike Parker wrote: This is my latest post in the GC series. I had promised the next one would look at non-GC allocation strategies, but as it got longer and longer I decided to break it up into two parts. This part covers stack allocations. The next one will deal with non-GC heap allocations. If my luck holds out, we're about to see a flurry of guest posts and collaborations over the next few weeks. If that pans out, I expect to publish the part two in mid-late August. The blog: https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/ Reddit: https://www.reddit.com/r/programming/comments/6ltfwx/go_your_own_way_part_one_of_two_on_nongc/ Nicely written as usual, keep those posts coming :P BTW, I noticed that the "Learn" button doesn't point to the DLang Tour, like it does on dlang.org, so I opened a PR to fix this: https://github.com/dlang/D-Blog-Theme/pull/21.
Go Your Own Way (Part One: The Stack)
This is my latest post in the GC series. I had promised the next one would look at non-GC allocation strategies, but as it got longer and longer I decided to break it up into two parts. This part covers stack allocations. The next one will deal with non-GC heap allocations. If my luck holds out, we're about to see a flurry of guest posts and collaborations over the next few weeks. If that pans out, I expect to publish the part two in mid-late August. The blog: https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/ Reddit: https://www.reddit.com/r/programming/comments/6ltfwx/go_your_own_way_part_one_of_two_on_nongc/
Re: Work on ARM backend for DMD started
DMD is a piece of shit, and adding another one ARM backend with all those bugs and low performance instead of improving ldc is wasting efforts. The only use of dmd is development because of compilation speed. But some persons have "cerveau lent" and just cannot realise it.
Re: Beta 2.075.0-b2
On Wednesday, 5 July 2017 at 17:59:16 UTC, Martin Nowak wrote: Second beta for the 2.075.0 release. Comes with a couple of more fixes for dmd, phobos, and dub: https://github.com/dlang/dmd/compare/v2.075.0-b1...v2.075.0-b2 https://github.com/dlang/phobos/compare/v2.075.0-b1...v2.075.0-b2 https://github.com/dlang/dub/compare/v1.4.0-beta.1...v1.4.0-beta.2 Downloads and changelog here: http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.075.0.html Please report any bugs at https://issues.dlang.org. - -Martin Installed on macOS via brew... pinver$ /usr/local/Cellar/dmd/2.075.0-b2/bin/dmd --version DMD64 D Compiler v2.074.1 /Paolo
Re: Release candidates vibe.d 0.8.0-rc.1 and vibe-core 1.0.0-rc.1
Am 04.07.2017 um 12:43 schrieb Szabo Bogdan: On Thursday, 22 June 2017 at 20:59:51 UTC, Sönke Ludwig wrote: Am 22.06.2017 um 20:52 schrieb aberba: [...] Agreed, there are several places in there that can be improved or made more consistent. The HTTP package (including WebSockets) is the next big part that is up for a complete redesign, also (finally) including HTTP/2 support. Since I'm really busy with another project I can't state a reliable schedule for this, but I'll try to start in the near future and will also to try to involve interested people in the design/development process as early as that makes sense. I can help... How can I contribute? When the initial design sketch is done, I'll probably just directly put that up as a repository, so that everyone can comment and improve. I will get back to you once that is done, would be great to get more support. There will also be all different kinds of things to do, since basically almost everything will have to be rewritten one way or another.
