Let's have out first biweekly over the next few (2) days.
I'd suggest to do it here on dmd-internals, as it's semipublic and
asynchronous.

Agenda:

- review last 2 weeks
- open issues blocking release
- plan remaining work for updated 2H15 mid-term plan (vision)
- eventually plan other work

Retrospective:

- Release

We're pretty late with the release, there has been little work on fixing
regressions.
I'm spending most of my time trying to finish the smart pointers/refs.

People are still surprised by the release, maybe we should publish dates for the next few releases in advance?

Little participation in the release (except from Kenji and Vladimir),
nobody worked on bugfixes before the first beta, still no changelog for
new stuff, time is spent on the usual news discussions, and normal pull
requests.
We cannot succeed by dumping code into the master branch.
It's important that we develop with the next release in mind.

Last time we discussed separate changelogs per repo, so that PRs can come with their corresponding changelog entry. Still sounds like a good idea to me.

- Trello

Please make the boards public as well Andrei, people say they can't see it.

Too little activity yet, any help needed?
It's a pity to see it getting talked down before anyone but me actually
started using it http://forum.dlang.org/post/556A992B.7080105@erdani.com.
But Andrei still seems to remember past failure
http://forum.dlang.org/post/mctauq$kc9$1@digitalmars.com.

It's of utmost importance that we coordinate our work better to utilize the little dev resources we have more efficiently.

- Forum

Thanks @Cybershadow.
Nice forum overhaul, fast search, keyboard shortcuts.
I'm missing the thread view.

=================================================================================

Finished Work:

My the last prerelease stories.

- core.aa proposal (https://trello.com/c/55mmbxq8/4-core-aa-proposal)

The discussion was not very fruitful.
http://forum.dlang.org/post/mjsma6$196h$1@digitalmars.com
Basically the only feedback came from IgorStepanov with whom I worked on
the last AA library attempt.

It seems that the issues of changing the existing AA are still underestimated. http://forum.dlang.org/post/ffnykfwzkqgxipyailvp@forum.dlang.org

Not sure how to drive this important topic forward against so much indifference. Seems like "the harder the topic, the shorter the debate" applies here as well (http://producingoss.com/en/common-pitfalls.html#bikeshed).

- Fix merging of coverage reports
(https://trello.com/c/iUVmhC1I/5-fix-merging-of-coverage-reports)

Druntime can now merge coverage reports (and even avoids race conditions),
We found this non-working while enabling coverage tests for dub.
https://github.com/D-Programming-Language/dub/pull/550
I still think merge by default would be a better choice.

Follow-up story coverage merge should detect changed source code. https://issues.dlang.org/show_bug.cgi?id=14790

- gdcproject - simplified download links for 4.9.2 https://trello.com/c/zpWDlmpU/10-gdcproject-simplified-download-links-for-4-9-2

We still manually update http://ftp.digitalmars.com/LATEST_GDC and Iain manually creates symlinks to simplify the download links for Travis-CI.

https://github.com/travis-ci/travis-ci/issues/3920#issuecomment-103121272

Need a follow-up to automate gdc symlinks.

- Release 2.068.0-beta1
(https://trello.com/c/7FucaqS5/11-release-for-2-068-0-beta1)

Went OKish.
Adding support for HOST_DMD was simple
(https://github.com/D-Programming-Language/installer/pull/124).
Some hacking required.
https://github.com/D-Programming-Language/phobos/pull/3433

Still need to compile all the mails I sent to Andrei into a nice wiki
page describing the whole process.
It would be great if more people than me could build a release.

- Follow-Up on postblit/destroyRecurse which are now provided by the
compiler
https://trello.com/c/rkIz1sDU/15-follow-up-on-postblit-destroyrecurse-which-are-now-provided-by-the-compiler-https-github-com-d-programming-language-druntime-pul

Asking people to follow-up on a PR is pretty unreliable and risks to
release incomplete/unfinished stuff.
Either we figure out how to better cooperate with contributors or we
must not merge code that requires more work.

It's tiresome that we keep producing incomplete features. https://github.com/D-Programming-Language/dmd/pull/4114#issuecomment-62203671

Maybe worth to do multiple/continuous reviews on a branch before making a PR, instead of splitting branch work into multiple PRs.

- Update threshold for binary size check (https://trello.com/c/O6c7XZrW/8-update-thresholds-for-binary-size-check)

Done by Walter, maybe follow-up with a more platform/optimization specific approach.

=================================================================================

Next 2 weeks:

- Finish SmartRef Implementation.
(https://trello.com/c/pTlDuyBD/16-finish-smartref-implementation)

I'm currently working on smart ptrs/refs, which will still take 1-2 full
days of work.
The complexity increased about twofold b/c of the need to hack around
attribute inference deficiencies, i.e. make the destructor of Unique
@nogc nothrow depending on the dtor of the payload. It's additionally
complicated by support for polymorphic conversion and the fact that base
classes might not have a dtor.
https://github.com/MartinNowak/phobos/commits/smartRefs

Maybe move that feature (or the attributes or the polymorphic
conversions) to 2.069 instead?

- Add support for classes to RefCounted.
(https://trello.com/c/c9HFOaBg/2-add-support-for-classes-to-refcounted)
- Overhaul Unique. (https://trello.com/c/l92LIsTh/3-overhaul-unique)

Merged with Finish SmartRef Implementation
(https://trello.com/c/pTlDuyBD/16-finish-smartref-implementation).
We need a holistic approach to smart ptrs, not partial/unsynchronized
work on Unique and RefCounted. That should also include support for weak
references.

- Investigate compiler slowdown
(https://trello.com/c/L0nV131G/17-investigate-compiler-slowdown).

I proposed an idea for a generic fix of the underlying problem. https://issues.dlang.org/show_bug.cgi?id=14431#c12

Kenji made a PR that seems to at least mitigate the slowdown, haven't yet reviewed it.

- Beta Building/Testing 2.068.0
(https://trello.com/c/8s6zLaMV/14-beta-building-testing-2-068-0)

Building the next beta. Support for beta testing.

- Finish/Approve/Merge Renamings for 2.068.0 (https://trello.com/c/zcywqyAA/18-finish-approve-merge-renamings-for-2-068-0)

Waiting for Andrei or Walter. https://github.com/D-Programming-Language/phobos/pull/3454

- Rangified functions no longer accept types that implicitly cast to
string
(https://trello.com/c/jtYFpydm/19-rangified-functions-no-longer-accept-types-that-implicitly-cast-to-string)

Important fix before the rangified phobos algos can be released.
Ideally Walter would do it.
Why was this resolution delayed until now?
The issue was know since almost the first rangifying PR.

- Thread cache for GC.
(https://trello.com/c/K7HrSnwo/28-thread-cache-for-gc)

Moved to backlog, no time to finish for 2.068

- Fix binary size for tempFile
(https://trello.com/c/jtmRtrHD/29-fix-binary-size-for-tempfile)

Ditto

=================================================================================

That's it from my side

-Martin

On 9 July 2015 at 15:14, Martin Nowak via dmd-internals < dmd-internals@puremagic.com> wrote:

> Retrospective:
>
> - Release
>
> We're pretty late with the release, there has been little work on fixing
> regressions.
> I'm spending most of my time trying to finish the smart pointers/refs.
>
> People are still surprised by the release, maybe we should publish dates for the next few releases in advance?
>
> Little participation in the release (except from Kenji and Vladimir),
> nobody worked on bugfixes before the first beta, still no changelog for
> new stuff, time is spent on the usual news discussions, and normal pull
> requests.
> We cannot succeed by dumping code into the master branch.
> It's important that we develop with the next release in mind.
>
> Last time we discussed separate changelogs per repo, so that PRs can come with their corresponding changelog entry. Still sounds like a good idea to me.
>
> - Trello
>
> Please make the boards public as well Andrei, people say they can't see it.
>
> Too little activity yet, any help needed?
> It's a pity to see it getting talked down before anyone but me actually
> started using it http://forum.dlang.org/post/556A992B.7080105@erdani.com.
> But Andrei still seems to remember past failure
> http://forum.dlang.org/post/mctauq$kc9$1@digitalmars.com.
>
> It's of utmost importance that we coordinate our work better to utilize the little dev resources we have more efficiently.
>
> - Forum
>
> Thanks @Cybershadow.
> Nice forum overhaul, fast search, keyboard shortcuts.
> I'm missing the thread view.
>
>
> =================================================================================
>
> Finished Work:
>
> My the last prerelease stories.
>
> - core.aa proposal (https://trello.com/c/55mmbxq8/4-core-aa-proposal)
>
> The discussion was not very fruitful.
> http://forum.dlang.org/post/mjsma6$196h$1@digitalmars.com
> Basically the only feedback came from IgorStepanov with whom I worked on
> the last AA library attempt.
>
> It seems that the issues of changing the existing AA are still underestimated. http://forum.dlang.org/post/ffnykfwzkqgxipyailvp@forum.dlang.org
>
>

I'm quite keen on this as-is, it just needs some time to bubble (real use).  I didn't take much notice of Igor's input at all.



> Not sure how to drive this important topic forward against so much indifference. Seems like "the harder the topic, the shorter the debate" applies here as well (http://producingoss.com/en/common-pitfalls.html#bikeshed).
>
> - Fix merging of coverage reports
> (https://trello.com/c/iUVmhC1I/5-fix-merging-of-coverage-reports)
>
> Druntime can now merge coverage reports (and even avoids race conditions),
> We found this non-working while enabling coverage tests for dub.
> https://github.com/D-Programming-Language/dub/pull/550
> I still think merge by default would be a better choice.
>
> Follow-up story coverage merge should detect changed source code. https://issues.dlang.org/show_bug.cgi?id=14790
>
> - gdcproject - simplified download links for 4.9.2
>
> https://trello.com/c/zpWDlmpU/10-gdcproject-simplified-download-links-for-4-9-2
>
> We still manually update http://ftp.digitalmars.com/LATEST_GDC and Iain manually creates symlinks to simplify the download links for Travis-CI.
>
> https://github.com/travis-ci/travis-ci/issues/3920#issuecomment-103121272
>
> Need a follow-up to automate gdc symlinks.
>
>
Recently got on-board with Semaphore-CI (better platform than Travis-CI IMO), currently investigating using their docker-beta platform to push out binary tarballs.

Download paths needs an overhaul.  In retrospect I think it's not a good idea to update D frontend versions in GCC release branches.  There's is just too much noise going on in resultant tarball names.  I'm of the opinion that it doesn't matter what version of the frontend is built against a GCC release, however end-users don't see it that way.  They want the latest D library with the version of GCC running locally. ;-)

Iain

On 07/09/2015 03:14 PM, Martin Nowak via dmd-internals wrote:
> Please make the boards public as well Andrei, people say they can't see it.

Done, turns out I can do that as well, b/c I created the boards. Thanks for the hint Steven.

> On 9 jul 2015, at 15:14, Martin Nowak via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> We cannot succeed by dumping code into the master branch. It's important that we develop with the next release in mind.

If you’re concerned about code added to the master branch that should not be part of the release, shouldn't there be a release branch then?

-- 
/Jacob Carlborg


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

> On 9 jul 2015, at 20:49, Martin Nowak via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> On 07/09/2015 03:14 PM, Martin Nowak via dmd-internals wrote:
>> Please make the boards public as well Andrei, people say they can't see it.
> 
> Done, turns out I can do that as well, b/c I created the boards. Thanks for the hint Steven.


Should there be a link from dlang.org <http://dlang.org/> to the Trello board? People have been complaining about there’s no road map since the D1 days.

-- 
/Jacob Carlborg

On 07/09/2015 03:45 PM, Iain Buclaw wrote:
> Recently got on-board with Semaphore-CI (better platform than
> Travis-CI IMO)

Well adding D to the list of supported PLs always helps our visibility,
but then again there is way more important stuff to do than adding a
Travis-CI alternative.
It's also an endless job to add support for all CI systems.
http://www.slant.co/topics/186/compare/~circleci_vs_shippable_vs_travis

> currently investigating using their docker-beta platform to push out
binary tarballs

For release building? Are you cross-compiling? That would be interesting for dmd as well. VirtualBox doesn't make things faster, but cross-compiling comes with it's own drawbacks.

> Download paths needs an overhaul.  In retrospect I think it's not a good idea to update D frontend versions in GCC release branches.

Not sure. In the long-run you want to move gdc into the gcc repo, so
gcc's version numbers should be dominant.
I think 4.9.2+2.068.0 perfectly makes sense.
How does gccgo handle this?

On 9 July 2015 at 21:09, Martin Nowak via dmd-internals < dmd-internals@puremagic.com> wrote:

> On 07/09/2015 03:45 PM, Iain Buclaw wrote:
> > Recently got on-board with Semaphore-CI (better platform than
> > Travis-CI IMO)
>
> Well adding D to the list of supported PLs always helps our visibility,
> but then again there is way more important stuff to do than adding a
> Travis-CI alternative.
> It's also an endless job to add support for all CI systems.
> http://www.slant.co/topics/186/compare/~circleci_vs_shippable_vs_travis
>
> > currently investigating using their docker-beta platform to push out
> binary tarballs
>
> For release building? Are you cross-compiling? That would be interesting for dmd as well. VirtualBox doesn't make things faster, but cross-compiling comes with it's own drawbacks.
>
>

Building cross-compilers is the end goal, yes.



> > Download paths needs an overhaul.  In retrospect I think it's not a good idea to update D frontend versions in GCC release branches.
>
> Not sure. In the long-run you want to move gdc into the gcc repo, so
> gcc's version numbers should be dominant.
> I think 4.9.2+2.068.0 perfectly makes sense.
> How does gccgo handle this?
>
>
Whatever is the current version of Go when GCC release freezes is the version that will be shipped with it.

If I imposed this more strictly, we would instead have:

4.8.4+2.064.2
4.9.2+2.065.0
5.1.0+2.066.1
6.0.0+2.067-dev

Yes, DMD releases take so long, they are pretty much in sync with GCC. (Although, still one release behind DMD by the time I manage to complete the merge ;-)

Iain

On 9 July 2015 at 21:09, Martin Nowak via dmd-internals < dmd-internals@puremagic.com> wrote:

> On 07/09/2015 03:45 PM, Iain Buclaw wrote:
> > Recently got on-board with Semaphore-CI (better platform than
> > Travis-CI IMO)
>
> Well adding D to the list of supported PLs always helps our visibility,
> but then again there is way more important stuff to do than adding a
> Travis-CI alternative.
> It's also an endless job to add support for all CI systems.
> http://www.slant.co/topics/186/compare/~circleci_vs_shippable_vs_travis
>
>
It's more that Travis' constraints are more harmful and stopped me getting any work done.

- The 40 minute time limit on build+tests aren't so bad, you can achieve
that with gdc if you build with parallelism, except that...
- The memory limit is capped at 3GB, meaning that builds will randomly die
depending on whether or not two (or more) large sources are compiled at the
same time.
- Infact, just linking the compiler is enough to hit the memory cap,
meaning that wonderful build and linker hacks are needed just to keep
resources down.
- There's also a timeout if 10 minutes go by without any logging (the
testsuite typically logs nothing except for failures, and may take up to 15
minutes to run), that's fine, I can just turn on verbose logging, except
that...
- Anything over the 1000th line is discarded by the build.

It took me about 30 attempts to build gdc + run testsuite on their platform.  Even then it failed twice every three builds for no reason other than bad races with parallel builds.

Conclusion: Travis is no good for large and/or serious projects.

Having a quick look, it appears that I'll run into similar problems with CircleCI (4GB hard memory limit, build/tests are timed out afer 180 seconds of silence) and Shippable (Again with 4GB memory, build/tests must complete in 60 minutes, cannot be silent for more than 10 minutes).

I actually had a good rant about this last month, because I can no longer wait for the broken auto-tester to start working on all platforms, but all alternates are useless offers for medium to large open source projects.

So it was quite a relief to find out that Semaphore offers:
- 4GB "soft" limit, doesn't actually kill your build/tests if you sometimes
exceed.
- 60 minute limit "per command", so you could have 24 commands that each
take 59 minutes and things will continue to build.

Everything I've thrown at it, it has consumed with delight and succeeded. This makes me a happy user.

Iain.

On 07/09/2015 09:03 PM, Jacob Carlborg wrote:
> Should there be a link from dlang.org <http://dlang.org/> to the Trello board? People have been complaining about there’s no road map since the D1 days.
> 
Mmh, let's see whether this gets traction.
It's also not a roadmap, the vision document is
(http://wiki.dlang.org/Vision/2015H1). The trello board is for
short-term planning, and it's separate b/c it's difficult to track
long-term goals when dealing with the messy details of short-term work.