On 09/09/2015 06:00 PM, Vladimir Panteleev via dmd-internals wrote:
> On Wednesday, 9 September 2015 at 19:50:12 UTC, Andrei Alexandrescu wrote:
>> That's how we got HHVM from 5x slower to 4x faster than the baseline:
>> by working on every percent. And by not letting things wiggle.
>
> I'd like to integrate http://digger.k3.1azy.net/trend/ with
> https://github.com/CyberShadow/DAutoTest so we get instant feedback for
> every PR, hopefully I'll find time for this this month.

That'd be awesome, thanks! -- Andrei

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 9 Sep 2015, at 21:45, Brad Roberts via dmd-internals wrote:
> I'm very much in favor of seeing shared libraries become a reality, but there's a necessary process that's needed to ensure the required behavior: backwards abi compatibility.  The major projects that ship shared libraries (ie, libgcc, libc, etc) have tooling (that I've never looked at) to detect breakage.  This covers both no changes to existing symbols as well as controlled and acknowledged introduction of new symbols.  Production quality shared library support is a big step up in responsibility.

Not really. Just increment the SOVERSION (or equivalent) on every single release. Then it won't be assumed to be backwards-compatible in the first place.

 — David
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 09/10/2015 12:00 AM, Martin Nowak via dmd-internals wrote:
> We should do more things in the compiler lazily and need a proper pipeline that keeps track of dependencies (and detects cycles).

Another bug cause by semantic order.

https://issues.dlang.org/show_bug.cgi?id=15044

It's clear that doing things like this

https://github.com/9rnsr/dmd/blob/d167403e777bcf91c50a7fd8eedf5100ac1ab50d/test/compilable/test14838.d#L19

or this

https://github.com/D-Programming-Language/dmd/blob/891d17a67d9e07af1b4743b85aaf79e120858a6d/src/dstruct.d#L379 https://github.com/D-Programming-Language/dmd/blob/891d17a67d9e07af1b4743b85aaf79e120858a6d/src/dstruct.d#L565

manually cannot workout. We need to explicitly declare such order dependencies and resolve them automatically.

On 09/09/2015 07:14 PM, Martin Nowak via dmd-internals wrote:
> Branching for 2.069.0 was planned in 2 weeks. Maybe we should delay that for another week for 2.068.2?

Because quite some work went into 2.068.2 and we still have quite some stuff to do, I'd suggest to delay 2.069.0 (the ddmd release) by 2 weeks.

Any objections?

Version | Date
------------------|----------
Branch+Beta 2.069 | 2015-09-20 -> 2015-10-04
Release 2.069.0 | 2015-10-04 -> 2015-10-18

Fine with me, thanks for the heads-up. I'll look into your blocked PRs. -- Andrei

On 09/17/2015 06:43 AM, Martin Nowak via dmd-internals wrote:
> On 09/09/2015 07:14 PM, Martin Nowak via dmd-internals wrote:
>> Branching for 2.069.0 was planned in 2 weeks. Maybe we should delay that
>> for another week for 2.068.2?
>
> Because quite some work went into 2.068.2 and we still have quite some
> stuff to do, I'd suggest to delay 2.069.0 (the ddmd release) by 2 weeks.
>
> Any objections?
>
> Version | Date
> ------------------|----------
> Branch+Beta 2.069 | 2015-09-20 -> 2015-10-04
> Release 2.069.0 | 2015-10-04 -> 2015-10-18
>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals