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 i
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
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 CRunt
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.
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)
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. dip
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
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
ag
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
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
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
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
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.
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
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
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
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 abl
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 w
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 o
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.
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
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
22 matches
Mail list logo
